Кратко

  • RFC 10032 задаёт AEGIS как аутентифицированное шифрование, генератор потока и код аутентификации сообщения. Для шифрования пара (ключ, nonce) должна быть одноразовой, а текст нельзя выпускать до проверки; поток намеренно отбрасывает тег; только MAC разрешает повторять пару с разными входами.
  • Номер IANA, пройденный тестовый вектор и показатель скорости не доказывают роль реального вызова. Нужна запись о назначении ключа, пространстве nonce, кодировании associated data, пути исполнения и барьере, удержавшем непроверенные байты.

RFC 10032 опубликован в сентябре 2026 года как Informational RFC в потоке IRTF и фиксирует консенсус CFRG. Это не стандарт IETF Standards Track. Документ описывает AEGIS-128L, AEGIS-256, а также векторные AEGIS-128X и AEGIS-256X, построенные на функции раунда AES.

IANA выделила AEAD-идентификаторы 32–37 базовым вариантам и формам X2/X4. Они согласуют имена. Они не указывают, был ли вызов AEAD, потоком или MAC, не кодируют длину тега, схему связанных данных, назначение ключа, выдачу nonce и поведение при ошибке.

Существующая статья BTW о RFC 10032 уже отделяет codepoint от квитанции о согласовании и живом применении. Здесь граница другая: после выбора семейства какая именно функция была вызвана и что вправе утверждать её результат?

AEAD ставит проверку перед выдачей текста

В роли AEAD шифрование принимает сообщение, associated data, ключ и nonce, возвращая шифротекст и тег. Расшифрование вычисляет ожидаемый тег, сравнивает его за постоянное время и отдаёт открытый текст только при успехе.

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

Для AEGIS-128L и AEGIS-128X документ допускает до 2^48 сообщений со случайными nonce под одним ключом при вероятности коллизии около 2^-33. Для AEGIS-256 и AEGIS-256X практический предел в данном анализе отсутствует. Это оценка случайных коллизий, а не разрешение сознательно повторять значение.

Вторая обязанность — хранение предварительного текста. При неверном теге непроверенный текст и вычисленный тег нельзя выдавать, а буфер текста следует затереть. Если до окончательного решения часть данных получила парсер, журнал, callback или база, барьер уже нарушен, даже когда публичная функция вернула ошибку.

Квитанция вызова должна связывать роль, вариант, длину тега, идентификатор ключа, событие назначения nonce, однозначную сериализацию associated data, результат проверки и ранние побочные эффекты. Тег проверяет биты под ключом, но не управляет приложением, которое могло действовать заранее.

Поток отказывается от аутентификации намеренно

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

Функция корректна в конструкции, которая понимает её свойства. Опасность создаёт наследование репутации. Телеметрия называет и aegis_stream(), и aegis_encrypt() «защищёнными AEGIS». Миграция сохраняет поле алгоритма, заменяя функцию. Другая команда ищет тег в соседнем слое, хотя тот удалён по определению.

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

Только MAC владеет исключением

MAC поглощает данные и выдаёт тег длиной 128 или 256 бит. RFC 10032 прямо говорит: лишь эта функция допускает одну пару (ключ, nonce) для разных входов.

Исключение относится к функции, а не ко всему AEGIS. Единая политика nonce способна перенести разрешение в шифрование. Криптографическое ядро не распознает ошибку полномочий и продолжит вычислять.

У MAC-тега есть отрицательные границы. При известном ключе можно построить входы с коллизией состояния, поэтому тег нельзя использовать как хеш. Его распределение не гарантировано равномерным, поэтому он не служит материалом для вывода ключа. Размер 128 или 256 бит не превращает его в digest или новый секрет.

Разделение должно исполняться архитектурой: связанные с ролью ID ключей, разные метки вывода, независимые распределители nonce и отказ принимать AEAD-ключ через STREAM или MAC. Память разработчика о примечании — не контроль.

Длина тега и связанные данные остаются решением протокола

В описанной игре 128-битный тег даёт примерно 64 бита key-commitment-безопасности, 256-битный — около 128. Codepoint не сообщает сделанный выбор.

Свойство зависит и от контроля над associated data. AEGIS полностью связывает ключ в ограниченном случае, когда противник ими не управляет. При их изменении цитируемый анализ позволяет эффективно найти несколько ключей, проверяющих один аутентифицированный шифротекст. Если протоколу нужна более сильная гарантия, он может хешировать данные функцией с нужной стойкостью либо связать однозначную кодировку через поле info KDF при указанных ограничениях.

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

Тестовые векторы не доказывают цепочку хранения

Обширные векторы RFC 10032 показывают соответствие фиксированных входов и выходов. Межреализационные тесты показывают согласие. Они не доказывают, что production вызвал правильную роль или закрыл ошибочный путь.

Негативные тесты должны провоцировать смешение: подать ключ одной роли другой и ждать отказ; повторить шифровальный nonce с новой длиной тега; не дать MAC-исключению изменить AEAD-распределитель; типизировать поток как неаутентифицированный; испортить шифротекст, тег и associated data и проверить отсутствие текста и эффекта; отклонить MAC-тег в hash/KDF API; подтвердить бинарный и CPU-путь; вести раздельные счётчики.

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

Минимальная квитанция роли соединяет цель и угрозы, роль, вариант и параллелизм, длину тега, личность и назначение ключа, пространство и назначение nonce, схему associated data, версию и путь библиотеки, проверку и стирание, границу выдачи, живые счётчики и решение приложения.

Доктрина минимальной начальной спецификации Lu Heng позволяет общему примитиву координировать реализации, не присваивая решения пользователей. Реестр называет, библиотека исполняет роль, протокол задаёт структуру, приложение разрешает последствие. Дисциплина слоёв реальности не даёт RFC, тесту или тегу занять власть следующего слоя.

Главный операционный вывод RFC 10032: общая механика не объединяет обязанности. Имя осталось тем же; квитанции должны оставаться раздельными.

Источники