CMAC почему К1 и К2

Question

http://en.wikipedia.org/wiki/CMAC

http://www.rfc -archive.org / getrfc.php? Rfc = 4493

Есть две клавиши K1 и K2.Существуют ли какие-либо другие причины, кроме того, что сообщения 1 отличаются от 10 ^ 127 (1 и 127 нулей)

Если сообщение имеет длину (а длина также является сообщением в формате CMAC), существуют ли какие-либо недостатки безопасности, использующие толькоодин случайно сгенерированный K?

Answer 1

Прежде всего, в AES-CMAC действительно есть только один ключ K - это единственный, который вы должны сгенерировать, чтобы ответить на ваш последний вопрос, и это явно указано в спецификации:

Алгоритм генерации подключа, Generate_Subkey (), принимает секретный ключ K, который является просто ключом для AES-128.

Ваш другой вопрос - зачем нам генерировать K1 и K2 из K - ответить немного сложнее, но на самом деле очень простое объяснение: устранить неоднозначность в аутентификации сообщений.

Для иллюстрации предположим, что мы берем двоичные ключи из статьи вики: K1 = 0101 и K2 = 0111. Теперь давайте поиграем с сообщением M = 0101 011. Поскольку M не состоит из полных блоков (три бита, а не четыре), мы должны заполнить его. Теперь у нас есть M ' = 0101 0111.

Чтобы сгенерировать MAC для этого сообщения, нам просто нужно XOR наши ключи в:

M'  = 0101 0111
K1  = 0101
K2  =      0111
MAC = 0000 0000

Если бы мы использовали K1 в обоих случаях, то у нас была бы следующая процедура:

M'  = 0101 0111
K1  = 0101
K1  =      0101
MAC = 0000 0010

Это все хорошо, но посмотрите, что происходит, когда мы пытаемся сгенерировать MAC для M '' = 0101 0111 (то есть нераспакованное сообщение M '' идентичны набранному сообщению M ').

M'' = 0101 0111
K1  = 0101
K1  =      0101
MAC = 0000 0010

Мы создали один и тот же MAC из двух разных сообщений! Использование второго ключа (который обладает некоторыми теоретико-числовыми свойствами, которые не позволяют ему быть проблемно «подобным» K1 ) предотвращает такую ​​неоднозначность.

Answer 2

Я не верю, что это имеет отношение к атакам с открытым текстом, и я не согласен с симметричными шифрами, которые к ним подвержены.Одно из условий защищенности шифра заключается в том, что он защищен при KPA, CPA (атаки с использованием выбранного открытого текста) и CCA (атаки с использованием выбранного шифрованного текста).

Если я не понимаю ваш вопрос, да, вам все еще нужны оба подраздела.K2 используется, когда блок не является полным блоком.,K1 и K2 генерируются не случайным образом, а получены из K. Есть ли причина, по которой вы не хотите создавать эти подразделы?

У кодов аутентификации, связанных с режимами цепочки, есть ряд недостатков.CBC-MAC гарантированно безопасен только для сообщений фиксированного размера.Безопасность полностью терпит неудачу для сообщений переменной длины, где последний блок дополняется.

Вы можете прочитать статью XCBC, чтобы увидеть, как работает атака:

"В качестве простого примера обратите внимание, что с учетом CBC MAC для одноблочного сообщения X произнесите T = CBCEK (X) злоумышленник немедленно знает MAC-адрес CBC для двухблочного сообщения X || (X ^ T), поскольку это снова T. "

[1] http://www.cs.ucdavis.edu/~rogaway/papers/3k.pdf

Answer 3

Я полагаю, что симметричные шифры подвержены атакам с открытым текстом, по крайней мере, так было в прошлом. А так как вы делаете часть открытого текста (шаблон заполнения), вы не хотите пропускать информацию о вашем ключе. Если вы можете извлечь некоторые биты ключа таким образом, вы сможете атаковать методом грубой силы последний блок, но все остальные блоки остаются в безопасности (по крайней мере, под этой атакой KP), поскольку они были зашифрованы с помощью K1.

Чтобы преодолеть ту же проблему, блочные шифры обычно работают в различных режимах, см .: http://en.wikipedia.org/wiki/Block_cipher_modes_of_operation. Не знаю, почему это очевидное решение не было учтено при разработке CMAC.