Где поместить 64-битный IV в 128-битный блок счетчика для режима CTR AES-128 в формате PIFF

Документы просто не дают ответа.

Microsoft попыталась объяснить предмет понятно, но все равно остается двусмысленность. По крайней мере, в нашем случае.

У нас есть зашифрованный поток MP4. Он содержит блоки «SampleEncryptionBox» или «PIFF», которые содержат 8-байтовые = 64-битные векторы инициализации для зашифрованных блоков. НО: фактический «блок счетчика» для расшифровки видеоданных, зашифрованных в «режиме счетчика AES-128», составляет 128-бит. Я не знаю, куда именно поставить капельницу!!

  • В документе PIFF говорится, что 16-байтовый IV — это весь блок счетчика (очевидно) для режима AES-CTR. . Кроме того, 8-байтовый IV помещается в начало блока счетчика для режима AES-ECB (стр. 17). Но для 8-байтового IV в режиме AES-CTR это ничего не говорит!

  • В этом документе RFC говорится, что 128-битное число должно состоять из 4-байтового одноразового номера + 8 -байт IV + 4-байтовый счетчик. А значение Nonce должно быть взято из дополнительных 4 байтов для основного 128-битного ключа AES. Я могу получить 128-битный ключ только по заголовку защиты, где мне взять 4-байтовый одноразовый номер??

Любые дополнительные знания будут высоко оценены.


encryption aes smooth-streaming
person uluorta    schedule 11.05.2014    source источник

Ответы (2)


arrow_upward
1
arrow_downward

Вместо этого попробуйте NIST SP 800-38A, раздел B.2. Обратите внимание, что этот документ является первым, на который ссылается документ Microsoft:

Второй подход к удовлетворению свойства уникальности сообщений состоит в том, чтобы присвоить каждому сообщению уникальную строку из b/2 битов (с округлением в большую сторону, если b нечетно), другими словами, одноразовый номер сообщения, и включить одноразовый номер сообщения в каждое сообщение. блок счетчика для сообщения. Ведущие b/2 бита (с округлением в большую сторону, если b нечетное) каждого блока счетчика будут одноразовым номером сообщения, а к оставшимся m битам будет применена стандартная функция приращения, чтобы обеспечить индекс для счетчик блокируется для сообщения. Таким образом, если N является одноразовым номером сообщения для данного сообщения, то j-й блок счетчика задается как Tj = N | [j]m, для j = 1...n. Количество блоков n в любом m сообщении должно удовлетворять условию n ‹ 2 . Должна быть установлена ​​процедура, обеспечивающая уникальность одноразовых номеров сообщений.

Обратите внимание, что вам потребуется 2 ^ 64 блоков данных, чтобы перейти к следующему "одноразовому номеру сообщения" или IV. Это всего лишь пример метода создания счетчика; к сожалению, NIST имеет плохую привычку не указывать какие-либо значения по умолчанию. Так что это также зависит от протокола, но чаще всего встречается выше.

person Maarten Bodewes    schedule 13.05.2014

arrow_upward
1
arrow_downward

Хорошо, я нашел объяснение. Это ясно написано в документе «ISO/IEC JTC 1/SC 29 N».

Если поле IV_size равно 8, то его значение копируется в байты с 0 по 7 поля InitializationVector, а байты с 8 по 15 поля InitializationVector устанавливаются равными нулю. Поле IV_size не должно быть 0, когда флаг IsEncrypted равен 0x1.

Режим AES-ECB не имеет к этому никакого отношения.

person uluorta    schedule 14.05.2014