Кратко

  • RFC 9771 делит привычные характеристики AEAD на четыре семейства. Если их смешать, верное утверждение об алгоритме может оказаться вводящим в заблуждение на границе системы.
  • Защищаемое решение требует паспорта свойства, который связывает точное понятие безопасности, конструкцию и версию, поведение API, негативные испытания, жизненный цикл ключей и интеграцию протокола.

Характеристика ещё не гарантия

«Аутентифицированное шифрование» звучит как завершённое решение. На деле это примитив, защита которого зависит от договора между алгоритмом, дисциплиной ключей и nonce, связанными данными, интерфейсом и состоянием протокола. RFC 9771, выпущенный Crypto Forum Research Group в составе IRTF в мае 2025 года, важен именно тем, что не сводит этот договор к единому знаку качества.

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

Обычный интерфейс из RFC 5116 получает ключ, nonce, связанные данные и открытый текст; расшифрование возвращает текст или ошибку. Даже здесь скрыта операционная обязанность: каждый вызов под одним ключом требует уникального nonce. Строка «AES-GCM» не говорит, кто обеспечивает уникальность, сохранится ли она после восстановления снимка, как параллельные отправители делят пространство и согласован ли счётчик у ускорителя и программного резерва.

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

Четыре семейства — четыре вида доказательств

Семейство Что меняется Что приложить
Обычная безопасность Базовая конфиденциальность и целостность шифртекста Конструкция, параметры, формальное понятие, конкретные границы, векторы и лимиты
Дополнительное свойство безопасности Противник получает повтор nonce, множество пользователей, утечку или ранний текст Отдельные требования к конфиденциальности и целостности, понятие, различия и тесты ошибочного применения
Свойство реализации Способ вычисления Измеренный путь, память и проходы, граница проверки, равенство аппаратного и резервного путей
Дополнительная функция Новый интерфейс: обновление или выбираемое расширение шифртекста Контракт API, новая базовая модель, переходы состояния, совместимость и ошибки

Разделение показывает типичную ошибку. «Один проход», «параллельный» и «потоковый» описывают вычисление, но сами не доказывают конфиденциальность или целостность. RFC 9771 замечает, что потоковой конструкции могут потребоваться поблочная безопасность и целостность при выдаче непроверенного текста. Тест пропускной способности не может быть паспортом безопасности потокового API.

Обратная ошибка тоже опасна. Формальный результат для конструкции не доказывает, что обёртка его сохраняет. Если расшифровщик отдаёт байты до проверки тега, приложение оказывается в модели RUP — выдачи непроверенного открытого текста. Обычная конфиденциальность уже невозможна, а цели целостности и осведомлённости о тексте меняются. Буферный и инкрементальный API на одном примитиве могут иметь разные свойства.

Дополнительная функциональность делает границу ещё заметнее. Инкрементальное и robust authenticated encryption вынесены в приложение RFC 9771, потому что требуют интерфейса шире обычного AEAD. Во втором случае вызывающая сторона выбирает расширение шифртекста, обменивая длину на наилучшую целостность при этой длине. Здесь robust не означает key robustness — иногда так называют привязку к ключу. Запись, сохранившая лишь слово «robust», уже потеряла смысловое различие.

Почти синонимы скрывают условия

Nonce-misuse resilience и nonce-misuse resistance кажутся взаимозаменяемыми, но RFC 9771 их различает. Resilience защищает сообщения со свежими nonce, даже если противник вызывает повторы в других местах. Resistance защищает и сообщения с повторившимся nonce, кроме неизбежной утечки при повторе того же текста под тем же nonce. Resistance влечёт resilience, обратное неверно.

Поэтому меняется план испытаний. Для resilience показывают, что инцидент не заражает свежий трафик. Для resistance дополнительно характеризуют сам затронутый трафик. AES-GCM-SIV в RFC 8452 — стандартизированная устойчивая к ошибочному применению конструкция. Это свойство не переносится на обычный GCM и не подтверждает управление ключами или ошибками во внешней системе.

У commitment похожая ловушка. Key commitment спрашивает, может ли шифртекст быть допустимым под разными ключами. Full commitment учитывает также nonce, связанные данные и открытый текст. Полное свойство влечёт ключевое, но не наоборот. Это становится эксплуатационным вопросом, когда успешное расшифрование используется для определения арендатора, счёта или контекста. Исследование атак на определение контекста показывает реальность такой неоднозначности. Однако паспорт всё равно должен назвать конструкцию, кодирование контекста, длину тега и формальное понятие: термин не свяжет то, что система не закодировала.

От заявления к паспорту свойства

Паспорт — компактный версионированный объект доказательств, понятный закупкам, инженерам безопасности, эксплуатации и реагированию. Сначала фиксируются точное свойство и семейство RFC 9771. «Конфиденциальность и целостность при ошибочном применении nonce» — утверждение; «более безопасные nonce» — реклама. Если конфиденциальность и целостность используют разные понятия, приводятся оба. Альтернативное понятие требует доказательства эквивалентности или раскрытия неэквивалентности.

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

Раздел API указывает входы, момент выдачи, границу проверки, порядок блоков, отмену и ошибки. Он назначает владельца nonce и связанных данных. Ничего ли не выдаётся при ошибке, возвращается ли буфер или часть текста, приходит ли ошибка после действия клиента — эти факты определяют реальную модель.

Негативные тесты выводятся из свойства: повтор nonce, неверный ключ, изменённые связанные данные, шифртекст из другого контекста, укороченный или поддельный тег, переставленные блоки, ранняя выдача, откат, восстановление, исчерпание счётчика, смена фазы ключа, расхождение software и offload. Тест наблюдает поведение, а не заменяет доказательство; доказательство не подтверждает соблюдение предпосылок API.

Жизненный цикл включает генерацию и вывод, идентичность ключа, область nonce и последовательности, параллелизм, лимиты, ротацию, уничтожение, резервирование, восстановление и суммирование по пользователям. RFC 8645 описывает механизмы смены ключа, но внедрение должно показать выбранный триггер и перекрытие состояний. Смена провайдера, offload, распределителя nonce, модели сохранения или ротации должна аннулировать паспорт.

Наконец, протокол заполняет разрыв между примитивом и сетью. TLS 1.3 строит nonce записей из состояния последовательности; QUIC добавляет номер пакета и фазу ключа. Повторы, защита от replay, восстановление, миграция, framing, привязка контекста, совместимость и аппаратная терминация требуют отдельной проверки.

Что покупатель может запросить сейчас

RFC 9771 позволяет сформулировать: «Для каждого заявленного нестандартного свойства AEAD предоставьте точное понятие безопасности, реализацию и версию, поведение API, сохраняющее условия, негативные тесты границы, контроль жизненного цикла ключей и охваченные протокольные пути».

Ответы «не поддерживается», «только на этом пути» или «не доказано при таком отказе» полезны: они создают границу, которую можно оценить, наблюдать и пересмотреть. Опасно имя свойства без владельца и срока действия — условный результат превращается в постоянную организационную память.

Источники