Кратко

  • RFC 3537 составлял запись из байта длины, HMAC-ключа и случайного заполнения, чтобы поместить переменную длину в обёртку 3DES или AES.
  • Успешное разворачивание возвращало указанные байты и проверяло целостность, но не связывало HMAC-алгоритм, назначение, субъекта или источник; любой владелец KEK мог создать принятую обёртку.

Пусть хранилище выдаёт запечатанную ленту ровно заказанной длины. Без наряда неизвестно, в каком станке она должна работать. RFC 3537 решал измерение и доставку, но не выдавал наряд.

Proposed Standard мая 2003 года закрывал несовместимость форматов. RFC 3217 был рассчитан на 3DES-ключи с битами чётности, RFC 3394 — на 64-битные блоки. HMAC-ключ мог иметь иную длину. RFC 3537 добавил внутреннюю запись, не создавая новую криптографическую примитиву.

Формат LENGTH || KEY || PAD включал один октет длины, соответствующее число октетов ключа и минимальное случайное заполнение до кратности восьми. При unwrap получатель вырезал KEY и отвергал остаток PAD длиннее семи октетов.

«Произвольная длина» освобождала от фиксированных размеров, но один октет не кодирует бесконечность. Это вывод из формата, а не прямо названный максимум. Тем не менее возможности линии важнее широкого слова во введении.

В 3DES-варианте восьмиоктетная контрольная сумма покрывала длину, ключ и PAD. Запись шифровалась с новым IV, IV добавлялся впереди, порядок октетов обращался, затем выполнялось шифрование с 4adda22c79e82105. AES-вариант передавал запись RFC 3394 и читал её только после внутренней проверки. Механика регистра A принадлежит статье RFC 3394; здесь важен отсутствующий тип выпущенных байтов.

В записи нет HMAC-алгоритма, протокола, арендатора, субъекта, ID, времени, срока или разрешённого класса сообщений. PAD защищён целостностью, но не означает цель. LENGTH отмечает конец ключа, не предел полномочий.

OID HMAC-with-3DES-wrap и HMAC-with-AES-wrap с обязательным параметром NULL называют способ упаковки. Они не называют будущий HMAC или сервис. Вывод HMAC-SHA-2 и производственного разрешения из «AES wrap» добавляет политику, которой нет в байтах.

RFC 2104 рекомендует длину хотя бы с выход хэша и ограничивает пользу размера выше блока. Однако unwrap не выбирает хэш и не проверяет его минимум. Корректная структура не является оценкой силы.

Раздел безопасности говорит: конфиденциальность и целостность не обязательно дают аутентификацию источника. Любой владелец KEK создаёт проходящую запись. Источник требует аутентифицированной доставки KEK или подписи. Успех называет домен KEK, но не конкретного автора.

Компрометация KEK раскрывает старые ключи и позволяет вводить новые допустимые обёртки. Если общая KEK служит идентичностью, ущерб распространяется на все доверяющие процессы. Владение и область получателей нужны отдельно.

IV 3DES должен быть свежим при каждом вызове, PAD случаен. Эта случайность формирует упаковку, а не служит HMAC-тегом или nonce будущей операции.

Единственная Verified errata меняет PAD теста с 38be62 на be62fe, согласованный с объединённой записью. Исправление Editorial и алгоритм не меняет.

RFC 5652, RFC 6031, RFC 4868, RFC 5649 и NIST SP 800-38F дают внешние структуры и современный контекст. Они не дописывают назначение внутрь LENGTH || KEY || PAD задним числом.

Доказательства должны отдельно хранить OID, KEK и право, целостность, длину, байты, аутентифицированный HMAC, ID, цель, субъекта, срок, выполнение, проверку и результат приложения. RFC 3537 сделал восстановление совместимым, но не превратил его во всеобщую авторизацию.

Источники