Кратко

  • RFC 3394 превращал n 64-битных блоков в n+1: регистр целостности участвовал в шести проходах и становился первым блоком шифртекста, а не заполнением после шифрования.
  • Развёртывание могло вернуть данные только при совпадении восстановленного регистра с ожидаемым начальным значением. Это не доказывало личность, разрешение, свежесть, сохранность KEK или дальнейшую пригодность ключа.

Длина результата сразу показывала особенность конструкции. На входе было n блоков, на выходе — n+1. Дополнительный блок не находился снаружи: он прошёл через механизм вместе с данными и затем охранял выход.

RFC 3394 вышел в сентябре 2002 года как Informational. Он перенёс спецификацию NIST AES Key Wrap в архив Интернета и явно отметил происхождение: большая часть текста взята у NIST, а заявления о безопасности принадлежат правительству США. Документ стандартизовал воспроизводимое преобразование, а не новую независимую экспертизу.

«Данные ключа» могли включать один ключ, несколько или сопутствующие сведения. KEK имел 128, 192 либо 256 бит. Вход делился минимум на два 64-битных блока; выход был ровно на один блок длиннее.

Данные помещались в R[1]R[n], а регистр A начинался с initial value. Шесть проходов по массиву давали 6n операций AES. Каждый шаг шифровал A | R[i]: нижняя половина заменяла R[i], верхняя после XOR со счётчиком t становилась новым A.

Финальный A превращался в C[0]. Это был не хвостовой padding, а состояние, смешанное с каждым блоком и позицией. Изменение данных, неверная KEK, иной порядок или другой IV-контракт должны были помешать обратному ходу восстановить ожидаемое начало.

Unwrap отменял операции и счётчики. Полученные регистры оставались кандидатами до проверки A. При подходящем начальном значении их разрешалось выдать; иначе реализация была обязана вернуть ошибку и никаких данных ключа. Проверка имела смысл лишь там, где код действительно удерживал вывод.

Стандартный IV состоял из повторённого A6 на 64 битах. RFC оценивал вероятность повреждённых данных при таком совпадении как 2^-64 в рамках криптографических предположений. Это не частота происшествий, не подпись отправителя и не подтверждение всей системы хранения.

Успех говорил о согласованности ciphertext, KEK, варианта и IV. Он не называл создателя, не выдавал полномочия, не доказывал свежесть или тайну KEK и не гарантировал назначение следующего шага. Украденная KEK способна создавать полностью приемлемые обёртки.

Тестовый вектор тоже доказывает только преобразование байтов. Он не подтверждает защиту от побочных каналов, изоляцию и производственное обращение с секретами. Сам RFC предупреждал: компрометация KEK может раскрыть всё, что ею защищено.

Исходная область требовала n >= 2 и длину, кратную 64 битам. Для иных длин и областей целостности предусматривались альтернативные initial values. Регистр был точкой расширения, а не декоративной константой.

RFC 5649 использовал её для Key Wrap with Padding. Его AIV соединяет 32-битную константу с 32-битным индикатором длины. При unwrap проверяются константа, допустимая длина и нулевое заполнение; для одного блока есть специальный путь. Новое утверждение о длине получило новый чек.

RFC 3565, JOSE и COSE добавили протокольные идентификаторы. Они выбирают вариант и размер KEK, но не превращают A в удостоверение личности и не смешивают KW с KWP. Errata исправляют формулировки, индексы и старую ссылку, не меняя шесть проходов и границу выдачи.

Минимальная начальная спецификация Lu Heng объясняет экономность: блоки, регистры, счётчик, проходы, IV и ошибка обеспечивали совместимость; хранение и разрешение оставались у компетентных систем. Приоритет работающего кода требует затем фактов о том, что реальная программа действительно не выдаёт данные при ошибке.

Дополнительный регистр отделял правдоподобные байты от выпущенного ключа. Его полномочие заканчивалось на этой границе. Он подтверждал внутреннюю форму пакета, но не право получить содержимое и не итог после открытия.

Источники