Кратко

  • RFC 2104 окружил существующий хеш двумя ключевыми проходами с разными постоянными дополнениями, не требуя менять код функции сжатия.
  • Хеш можно было заменить, а результат — усечь; поэтому алгоритм, ключ, точное представление сообщения и длина тега входят в проверяемый контекст.
  • Совпадение HMAC само по себе не доказывает уникального отправителя, полномочия, свежесть, канонизацию, конфиденциальность, доставку или корректную реализацию.

Исторически важной деталью HMAC была не новая хеш-функция, а способ безопаснее использовать уже имеющиеся. В 1997 году быстрый код MD5 и SHA-1 был широко доступен. Протоколам требовалась аутентификация с секретным ключом, но простое добавление секрета к сообщению не давало ясной и исследованной конструкции.

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

Один хеш, два разделённых домена

В RFC 2104 хеш обозначен H, размер входного блока — B, длина результата — L. Ключ длиннее B сначала хешируется, короткий дополняется нулями. Затем применяются две разные константы длины B: ipad из повторяющегося байта 0x36 и opad из 0x5c.

Формула имеет вид H((K xor opad) || H((K xor ipad) || text)). Во внутреннем проходе сообщение следует за первым производным от ключа блоком. Во внешнем — результат внутреннего прохода следует за другим блоком. Сам код H не меняется.

Так сохранялись производительность и готовые реализации, упрощалась работа с ключом и предусматривалась замена хеша. Семантика text, способ кодирования, право отправлять команду и действие после проверки оставались задачами протокола и приложения.

Предвычисленное состояние наследует секретность

Для коротких сообщений документ разрешает заранее вычислить состояния после внутреннего и внешнего ключевых блоков. Это экономит два шага сжатия на сообщение и не влияет на совместимость.

Но RFC требует защищать такие состояния как ключи. Производный объект может сохранять операционную силу исходного секрета. Защита файла K при утечке многократно используемого состояния означает защиту формы, а не полномочия.

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

Тег относится к байтам, а не к намерениям

Приложение может передавать только левые t бит результата. Усечение меняет сложность угадывания, поэтому длина должна быть частью протокола. Запись «HMAC верен» неполна без алгоритма, идентификатора и эпохи ключа, точных байтов и длины сравнения.

HMAC не понимает, что два JSON-объекта или строки Unicode имеют одинаковый смысл. Иной порядок полей, кодировка или нормализация меняют тег. И наоборот: обе стороны могут одинаково обработать неправильный набор полей и получить совпадение. Канонизация предшествует MAC и не возникает из него.

Симметричный общий ключ ограничивает атрибуцию. Любой законный держатель способен создать правильный тег. Проверка не выбирает одного человека, процесс или узел среди них. Это не цифровая подпись и не независимое доказательство неотказуемости.

Тестовые векторы сделали правило исполнимым

RFC 2202 в том же 1997 году опубликовал известные ключи, сообщения и результаты HMAC-MD5 и HMAC-SHA-1. Независимые реализации получили общий байтовый ориентир.

Успех на этих примерах подтверждает конкретные пути. Он не покрывает все длины, ошибки, гонки, сравнение с постоянным временем, выбор производственного ключа или защиту от повтора. Совместимость примитива — важная квитанция, но не сертификат системы.

Заменяемость не означала автоматическую миграцию

MD5 и SHA-1 были примерами своего времени, а H оставался абстрактным. Позднее RFC 4868 определил HMAC-SHA-256, -384 и -512 для IPsec. RFC 6151 пересмотрел оценку MD5 и исключил HMAC-MD5 из новых проектов протоколов.

Композиция пережила ранние алгоритмы. Но переход всё равно требовал идентификаторов, согласования, кода, политики, тестов и смены ключей. Удачный интерфейс уменьшает связанность, а не устраняет организационную цену обновления.

Позднейший стандарт NIST FIPS 198-1 показывает институциональный охват HMAC. Долговечность схемы не делает каждую начальную реализацию вечной.

Решение о доверии начинается после сравнения

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

RFC 2104 дал Интернету строгий и тонкий общий блок. Два прохода сделали MAC переносимым. Доверие по-прежнему строилось вокруг него.

Источники