Кратко
- RFC 9980 разрешает на этапе миграции зашифровать одно сообщение и для PQ/T-, и для традиционных получателей, но это не делает сообщение постквантово конфиденциальным, если один из путей остаётся традиционным.
- Проверять нужно не наличие нового ключа в каталоге, а фактический набор ключей получателей, выпущенные PKESK и решение сохранить каждый путь совместимости.
У конверта есть собственное свойство
В каталоге может появиться ключ ML-KEM-768+X25519, и отчёт о миграции поспешит объявить адресата «готовым к постквантовой криптографии». Такая запись означает только наличие ключевого материала с определённым идентификатором алгоритма. RFC 9980 не подтверждает, что конкретный клиент умеет им пользоваться, что этот ключ был выбран при данной отправке, что он соответствует ожидаемой личности или что для того же содержимого не был оставлен другой путь расшифрования.
OpenPGP допускает несколько пакетов Public Key Encrypted Session Key — PKESK — в одном сообщении. Каждый пакет даёт одному из ключей получателя возможность получить один и тот же ключ сеанса содержимого. Раздел 8.1 RFC 9980 разрешает при переходе шифровать одновременно для ключей PQ(/T) и традиционных ключей, чтобы старые реализации не утратили возможность обмена. Это осмысленное решение о непрерывности, но оно не убирает традиционный путь. Раздел 3.1 прямо ограничивает вывод: если не все ключи, использованные в пакетах получателей, относятся к PQ(/T), конфиденциальность сообщения не является постквантовой.
Из этого не следует, что любого традиционного получателя нужно безусловно заблокировать. Контрагент может ещё не обновить программу, восстановительный контакт может быть заранее одобрен, а у отдельного класса сообщений может быть ограниченное обязательство по непрерывности. Но такой путь меняет криптографическое свойство именно этого письма. Его нельзя спрятать в настройке рассылки. Нужны класс сообщения, путь получателя, причина, ответственный, срок и план замены.
Составной ключ и второй получатель различаются по форме
Слово «гибридный» легко скрывает ключевое различие. В составной схеме шифрования RFC 9980 ML-KEM и ECDH KEM работают внутри одного ключа получателя PQ/T. Отдельные инкапсуляции вместе с ECDH-шифртекстом, открытым ключом получателя и привязкой к контексту протокола поступают в комбинирующую функцию, которая выводит ключ для обёртывания ключа сеанса. Это одна определённая конструкция для одного пути; её компоненты не являются альтернативными адресатами.
Традиционный PKESK, стоящий рядом с PQ/T-PKESK, имеет иную семантику. Он открывает самостоятельную дополнительную дорогу к тому же ключу сеанса. Поэтому наличие составного PQ/T-алгоритма не повышает автоматически свойство всего письма, если в нём есть отдельный классический пакет. Надёжный вопрос аудита звучит не «есть ли в сообщении гибридная криптография?», а «какие ключи получателей действительно могут открыть этот конверт?». На него отвечает форма отправленных пакетов, а не список купленных или заявленных возможностей.
Подпись сохраняет совместимость по другой логике
Для подписей RFC 9980 описывает отдельный переход. Отправитель может приложить традиционную и PQ(/T)-подпись, чтобы старый проверяющий ещё мог опереться на традиционную; подпись только PQ/T не обладает обратной совместимостью. Новый проверяющий вправе принять обе. Если ему известно, что у партнёра уже есть ключ подписи PQ/T, и риск криптографически значимого квантового компьютера существенен для данного контекста, он может предпочесть игнорировать традиционную подпись партнёра.
Это не правило об идентичности, полномочии или истинности текста. Действительная подпись не доказывает деловое разрешение отправителя, согласие получателя или безопасность конечной точки. Она показывает, что политика проверки подписи и политика выбора получателей для шифрования имеют разные объекты и последствия. Один индикатор «PQC включена» не может заменить обе.
Достаточное свидетельство без нового архива переписки
Для проверки не требуется хранить текст каждого письма. Достаточно зафиксировать класс сообщения, выбранные ключи, версии ключей и пакетов, алгоритмы, выпущенные PKESK, уместное подтверждение способности и решение разрешить традиционный путь. Большинство асимметричных алгоритмов PQ(/T) связано с ключами и сертификатами v6 или новее; ML-KEM-768+X25519 допускается как исключение в некоторых шифрующих подключах v4. Реестр IANA с идентификаторами 30–36 помогает прочитать пакет. Он не доказывает внедрение, поведение конкретного продукта или принятую организацией политику.
Такой минимальный журнал сохраняет доказательство криптографической конструкции и принятого исключения, не превращая миграцию в ещё одну систему наблюдения за содержанием и связями переписки.
Источники
- RFC 9980 — Post-Quantum Cryptography in OpenPGP
- RFC Editor information — RFC 9980
- IETF Datatracker — RFC 9980
- RFC 9580 — OpenPGP
- RFC 9794 — Terminology for Post-Quantum Traditional Hybrid Schemes
- IANA OpenPGP Public Key Algorithms
- NIST FIPS 203 — ML-KEM
- NIST FIPS 204 — ML-DSA
- NIST FIPS 205 — SLH-DSA
- Heng Lu — Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption
Обзор для участников
Подробный контекст профиля
Войдите с подходящим уровнем подписки, чтобы открыть полный обзор и примечания к источникам.
Только для Стратегического сообщества
Стратегическое сообщество
Открыто всем читателям. Вступите и войдите, чтобы открыть обзоры профилей.
Вступить в Стратегическое сообществоТолько для Альянса лидеров
Альянс лидеров
Для проверенных владельцев IP-активов и руководителей. Войдите, чтобы открыть обзоры Альянса.
Вступить в Альянс лидеров

