Почему AES-ключ в gcm-режиме длиннее на 4 байта?

Я использую ip xfrm под Linux, чтобы добавить в систему IPsec SA с AES в режиме GCM.

Команда, которую я использую, выглядит так:

ip xfrm state add src 10.66.21.164 dst 10.66.21.166 proto esp spi 0x201 mode transport aead "rfc4106(gcm(aes))" 0x010203047aeaca3f87d060a12f4a4487d5a5c335 96

Теперь мне интересно: ключ имеет длину 20B = 160b. Обычный ключ AES имеет длину 128 бит, и, как видно выше, длина IV составляет 96 бит. Если я удлиняю или укорачиваю ключ, он не работает, поэтому очевидно, что ожидаемый ввод равен (sizeof(AES)=128b) (конечно, он работает и с 256b) + 32b в длину.

Почему это так? Единственное, что я знаю, имеет длину 4 байта в этом контексте — это unsigned int, который является типом данных переменной IV-длины, но это не имеет ничего общего с ключом. Разве ключ плюс IV не должен быть длиной 224b (128 + 96 для IV)?


person Marste    schedule 16.03.2014    source источник
comment
О, вы, конечно, правы. Я случайно скопировал AES-128. Во всяком случае, этот ключ имеет длину 128 байт (16 байт) + 4 байта дополнительно, я соответствующим образом отредактировал текст. Я также не могу представить, что эти 4B являются uint длины IV. Но я просто не могу понять, что это такое. Это должно иметь какое-то отношение к обязательному IV.   -  person Marste    schedule 17.03.2014
comment
Нет, это соль, см. мой ответ. Хотя на самом деле это конец.   -  person Maarten Bodewes    schedule 17.03.2014


Ответы (1)


Значение 96 в вашей команде — это размер тега аутентификации. Тег аутентификации является частью сообщения в сеансе, его не нужно указывать. То же самое касается IV, он генерируется протоколом для каждого сообщения.

Материал ключа состоит из 16-байтового (128-битного) ключа AES и 4-байтовой (16-битной) соли в шестнадцатеричном формате, в котором используется 2 символа на байт.

KEYMAT, запрошенный для каждого ключа AES-GCM, составляет 20 октетов. Первые 16 октетов представляют собой 128-битный ключ AES, а оставшиеся четыре октета используются в качестве солт-значения в одноразовом номере.

Источник: RFC 4106.

person Maarten Bodewes    schedule 16.03.2014
comment
Если не уверены, прочтите стандарт. Я тоже не шучу; в RFC все четко указано и легко читается. Я вижу, как люди часами спорят об интерпретации, прежде чем я вступаюсь и просто цитирую стандарт. - person Maarten Bodewes; 17.03.2014