Кратко

  • RFC 10032 — информационная публикация потока IRTF, отражающая консенсус CFRG, а не требование Standards Track IETF. Шесть назначений IANA дают стабильные имена, но не обязывают к внедрению.
  • Реестр различает AEGIS-128L, AEGIS-256 и четыре параллельные формы X2/X4, однако не кодирует выбор 128- или 256-битного тега. Параллельные режимы необязательны и требуют согласия всех сторон по точному варианту.
  • Самотест библиотеки подтверждает результат примитива на фиксированных векторах. Он не подтверждает согласование узлов, загруженный бинарный файл и путь CPU, построение nonce и связанных данных или защиту реального трафика.
  • Квитанция хранения алгоритма должна связать документ и реестр, профиль протокола, аутентифицированный выбор, код и тег, жизненные циклы ключа и nonce, кодирование связанных данных, путь выполнения, тесты, отказы, счётчики, резервный режим и откат.

Реестр отвечает на вопрос «как назвать»

IANA назначила 32 для AEAD_AEGIS128L, 33 для AEAD_AEGIS256, 34 и 35 для AEGIS-128X2/X4, а 36 и 37 для AEGIS-256X2/X4. Благодаря этому спецификации не используют один публичный номер для несовместимых алгоритмов, а конфигурации могут однозначно ссылаться на вариант.

Но номер не является протоколом сеанса. RFC 5116, создавший общий интерфейс и реестр AEAD, прямо говорит: регистрация не означает одобрения алгоритма или его безопасности. Интерфейс также не задаёт защиту от повторов и политику доступа. Это решения вызывающего протокола и эксплуатации.

RFC 10032 содержит определения, параметры, эксплуатационные указания и тестовые векторы. Он не задаёт единого согласования для TLS, IPsec, QUIC, хранилища или прикладного канала. Профиль должен решить, предлагается ли AEGIS, как идентификатор соотносится с конфигурацией, какова длина тега, откуда берутся ключи и nonce, какие байты образуют связанные данные и как обрабатывается ошибка аутентификации.

Поэтому «библиотека содержит AEGIS» — утверждение о возможности. «Этот сеанс выбрал AEGIS-128X2 с такими параметрами» — утверждение о согласии и выполнении. Между ними необходима запись.

Поток RFC определяет границы утверждения

RFC 10032 опубликован в сентябре 2026 года в потоке IRTF как Informational. Он представляет консенсус CFRG, но прямо указывает, что не является продуктом или стандартом IETF и что результаты IRTF могут оказаться непригодными для развёртывания.

Это не оценка качества, а точное описание полномочий и проверки. RFC 5743 описывает подготовку в исследовательской группе, рассмотрение IRSG и проверку конфликтов IESG. RFC 7841 отделяет документы не-IETF-потоков от общеорганизационного рассмотрения и одобрения стандартов IETF.

Следует хранить четыре самостоятельных факта: исследовательский консенсус CFRG, разрешение IRSG на публикацию, проверку конфликта со стандартизацией со стороны IESG и выделение уникальных номеров IANA. Ни один не означает принятия протоколом, включения по умолчанию в продукте или выбора парой узлов.

20 сентября публичная страница IANA показывала все шесть строк, но в ссылке ещё стоял draft-18, а датой обновления было 7 июля. Эта наблюдаемая задержка не делает назначения недействительными. Она показывает, зачем отдельно датировать снимки публикации и реестра.

Длина тега находится вне кодовой точки

AEGIS-128L использует 128-битные ключ и nonce, AEGIS-256 — 256-битные. Оба допускают теги аутентификации длиной 128 или 256 бит. Шесть имён IANA кодируют семейство и, для параллельных форм, степень X2/X4, но не длину тега.

Это меняет и свойство безопасности, и формат на проводе. RFC 10032 оценивает работу для описанного свойства обязательности примерно как 2^64 для 128-битного тега и 2^128 для 256-битного. Два узла могут согласовать код 32, но ожидать разные границы тега.

Нужно также закрепить представление: шифротекст и тег могут передаваться отдельно или вместе, когда тег идёт сразу после шифротекста. Одна запись «AEGIS-128L» не показывает, сколько бит разобрал получатель.

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

Параллелизм выбирает не только скорость

AEGIS-128X и AEGIS-256X рассчитаны на широкие векторные регистры и векторные AES-инструкции; X2 и X4 обозначают степени параллелизма два и четыре. Выигрыш зависит от архитектуры и реализации.

RFC 10032 задаёт ограничение: протоколу следует выбирать параллельную форму лишь тогда, когда все стороны согласны с конкретным вариантом. AEGIS-128L и AEGIS-256 должны оставаться вариантами по умолчанию, а реализация может вовсе не включать параллельные формы.

Поэтому быстрый тест X4 не создаёт переносимую криптосистему. У удалённой стороны может быть только базовый вариант; бинарный файл может быть собран без X-пути; миграция виртуальной машины может изменить доступные инструкции; диспетчер может перейти на резервный путь, пока настройка продолжает говорить «AEGIS».

Нужно различать предложение и выбор протокола, точную возможность каждого узла и действительно выполненный путь. Эти сведения связаны, но не взаимозаменяемы.

Большой nonce всё равно требует владельца

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

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

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

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

Вектор проверяет примитив, а не эксплуатацию

RFC 10032 содержит множество фиксированных векторов для AESRound, базовых алгоритмов, X2/X4 и MAC. Они выявляют ошибки порядка байтов, финализации, неполных блоков и образования тега. Сравнение независимых реализаций усиливает проверку.

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

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

Четырнадцать частей квитанции

Предлагаемая квитанция — редакционный операционный контроль Daniel Kade, а не поле RFC 10032 и не сертификат IETF, IRTF, CFRG или IANA.

Первое: идентичность документа, поток, категория, снимки публикации, исправлений и IANA. Второе: вызывающий протокол, версия, профиль и поколение конфигурации. Третье: аутентифицированная запись предложения и выбора либо эквивалентное доказательство согласия.

Четвёртое: номер и точная базовая, X2- или X4-форма. Пятое: длина тега и представление. Шестое: возможности сторон и поведение при отсутствии поддержки. Седьмое: происхождение, вывод, контекст, эпоха, идентификатор и стирание ключа.

Восьмое: построение и сохранение nonce, область уникальности, перезапуск и счётчик на ключ. Девятое: поля связанных данных и каноническое кодирование. Десятое: сборка библиотеки, путь CPU/вектора и резерв. Одиннадцатое: положительные векторы, межреализационные и негативные тесты.

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

Реестр не доказывает рукопожатие; рукопожатие — сохранение nonce; вектор — загруженный бинарный файл; пакет без эпохи ключа и правил связанных данных — основание приёма. Квитанция нужна, чтобы эти разные утверждения не исчезли в одном слове «поддерживается».

Источники