Квантовый интернет 2025: Новая эра кибербезопасности уже здесь

На этой неделе, последней неделе октября 2025 года, мы достигли важной вехи в области безопасности Интернета: большинство инициируемого человеком трафика в Cloudflare использует постквантовое шифрование, нивелируя угрозу атак «собрать сейчас/расшифровать позже».

Мы хотим использовать этот радостный момент, чтобы дать обновленную информацию о текущем состоянии перехода Интернета на постквантовую криптографию и о долгом пути вперед. Наш последний обзор был 21 месяц назад, и с тех пор многое произошло. Многое прошло так, как мы предсказывали: финализация стандартов NIST; широкое внедрение постквантового шифрования; более детальные дорожные карты от регуляторов; прогресс в создании квантовых компьютеров; некоторая криптография была взломана (не беспокойтесь: ничего близкого к развернутому); и была предложена новая захватывающая криптография.

Но были и несколько сюрпризов: произошел гигантский скачок в прогрессе к Q-дню за счет улучшения квантовых алгоритмов, и у нас был серьезный испуг из-за нового квантового алгоритма. Мы охватим все это и многое другое: что мы ожидаем в ближайшие годы; и что вы можете сделать сегодня.

Сначала о главном: почему мы меняем нашу криптографию? Из-за квантовых компьютеров. Эти удивительные устройства, вместо того чтобы ограничиваться нулями и единицами, вычисляют, используя больше того, что нам фактически предоставляет природа: квантовую суперпозицию, интерференцию и запутанность. Это позволяет квантовым компьютерам преуспеть в определенных очень специфических вычислениях, особенно в моделировании самой природы, что будет очень полезно при разработке новых материалов.

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

К сожалению, квантовые компьютеры также преуспевают во взломе ключевой криптографии, которая до сих пор широко используется сегодня, такой как RSA и эллиптические кривые (ECC). Таким образом, мы переходим к постквантовой криптографии: криптографии, разработанной для устойчивости к квантовым атакам. Мы обсудим точное влияние на различные типы криптографии позже.

Пока что квантовые компьютеры довольно слабы: сегодня они просто недостаточно хороши, чтобы взломать какие-либо реальные криптографические ключи. Это не значит, что нам еще не стоит беспокоиться: зашифрованный трафик можно собрать сегодня и расшифровать после Q-дня: дня, когда квантовые компьютеры станут способны взломать до сих пор широко используемую криптографию, такую как RSA-2048. Мы называем это атакой «собрать-сейчас-расшифровать-позже».

Если использовать факторизацию в качестве ориентира, квантовые компьютеры вообще не впечатляют: самое большое число, факторизованное квантовым компьютером без «читерства», — это 15, рекорд, который легко побить различными забавными способами. Возникает соблазн игнорировать квантовые компьютеры, пока они не начнут превосходить классические в факторизации, но это было бы большой ошибкой. Даже консервативные оценки помещают Q-день менее чем через три года после дня, когда квантовые компьютеры превзойдут классические в факторизации. Итак, как мы отслеживаем прогресс?

В движении к Q-дню следует учитывать две категории: прогресс в квантовом оборудовании и улучшения алгоритмов для программного обеспечения, работающего на этом оборудовании. Мы видели значительный прогресс на обоих фронтах.

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

Существуют большие различия между различными типами технологий, используемых для создания квантовых компьютеров: кремниевые квантовые компьютеры, кажется, хорошо масштабируются, быстро выполняют инструкции, но имеют очень шумные кубиты. Это не значит, что они бесполезны: с помощью квантовых кодов коррекции ошибок можно эффективно превратить миллионы шумных кремниевых кубитов в несколько тысяч высокоточных, чего может быть достаточно, чтобы взломать RSA. Квантовые компьютеры на ионных ловушках, с другой стороны, имеют гораздо меньше шума, но их было сложнее масштабировать. Всего несколько сотен тысяч кубитов на ионных ловушках потенциально могут опустить занавес на RSA-2048.

^{Таймлапс современного состояния в квантовых вычислениях с 2021 по 2025 год по количеству кубитов на оси x и шуму на оси y. Точки в серой области — это различные существующие квантовые компьютеры. Как только заштрихованная серая область достигнет самой левой красной линии, у нас будут проблемы, так как это означает, что квантовый компьютер может взламывать большие ключи RSA. Составлено Сэмюэлем Жаком из Университета Ватерлоо.}

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

А именно, на этих графиках прогресс в квантовых компьютерах, кажется, остановился за последние два года, тогда как для экспертов анонс Google Willow в декабре 2024 года, который ничем не примечателен на графике, на самом деле является настоящей вехой, достигшей первый логический кубит в поверхностном коде масштабируемым образом. Цитируя Сэма Жака:

Когда я впервые прочитал эти результаты [достижения Willow], я почувствовал озноб от «О, вау, квантовые вычисления на самом деле реальны».

Это настоящая веха, но не неожиданный скачок. Снова цитируя Сэма:

Несмотря на мой энтузиазм, это более или менее то, где мы и должны быть, и, возможно, даже с небольшим опозданием. Все большие прорывы, которые они продемонстрировали, — это шаги, которые нам нужно было сделать, чтобы хотя бы надеяться достичь 20-миллионного кубитного устройства, способного взломать RSA. Никаких неожиданных прорывов нет. Думайте об этом как об увеличении плотности транзисторов в классических чипах каждый год: впечатляющее достижение, но в конечном счете — обычная рутина.

Обычная рутина — это тоже стратегия: подход со сверхпроводящими кубитами, которого придерживается Google для Willow, всегда имел самый ясный путь вперед, атакуя трудности в лоб и требуя наименьших скачков в инженерии.

Microsoft придерживается противоположной стратегии со своей ставкой на топологические кубиты. Это кубиты, которые в теории в основном не подвержены влиянию шума. Однако они еще не полностью реализованы в аппаратном обеспечении. Если их можно будет построить масштабируемым образом, они будут намного превосходить сверхпроводящие кубиты. Но мы даже не знаем, можно ли их построить в принципе. В начале 2025 года Microsoft анонсировала чип Majorana 1, который демонстрирует, как их можно построить. Однако чип далек от полного демонстратора: он не поддерживает никаких вычислений и поэтому даже не появляется в предыдущем графике сравнения Сэма.

Между топологическими и сверхпроводящими кубитами существует множество других подходов, которые pursue лаборатории по всему миру и которые появляются на графике, такие как QuEra с нейтральными атомами и Quantinuum с ионными ловушками.

Прогресс на стороне оборудования в достижении Q-дня получил несравненно больше всего внимания прессы. Однако самый большой прорыв за последние два года произошел не на стороне оборудования.

Мы думали, что нам понадобится около 20 миллионов кубитов при использовании сверхпроводящего подхода для взлома RSA-2048. Оказалось, что мы можем обойтись гораздо меньшим количеством. В ошеломляюще комплексной статье июня 2025 года Крейг Гидни показывает, что с помощью умных оптимизаций квантового программного обеспечения нам нужно меньше одного миллиона кубитов. Именно поэтому красные линии на графике Сэма выше, отмечающие размер квантового компьютера для взлома RSA, резко смещаются влево в 2025 году.

Чтобы оценить масштаб этого достижения, давайте просто сделаем смелое предположение и скажем, что Google сможет поддерживать некий закон Мура и удваивать количество физических кубитов каждые полтора года. Это гораздо более быстрый темп, чем демонстрировал Google до сих пор, но также не немыслимо, что они смогут достичь этого, когда будет заложен фундамент. Тогда достижение 20 миллионов кубитов заняло бы до 2052 года, но всего до 2045 года для достижения одного миллиона: Крейг в одиночку приблизил Q-день на семь лет!

Насколько дальше могут зайти программные оптимизации? Снижение ниже 100 000 сверхпроводящих кубитов кажется Сэму невозможным, и он ожидает, что для взлома RSA-2048 потребуется более 242 000 сверхпроводящих кубитов. При нашем смелом предположении о прогрессе квантовых компьютеров это соответствовало бы Q-дню в 2039 и 2041+ годах соответственно.

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

На алгоритмической стороне мы можем увидеть не только улучшения существующих квантовых алгоритмов, но и открытие совершенно новых квантовых алгоритмов. В апреле 2024 года Илей Чен опубликовал препринт, утверждая, что нашёл такой новый квантовый алгоритм для решения определённых решёточных проблем, которые близки, но не идентичны тем, на которые мы опираемся для развёртываемой нами постквантовой криптографии. Это вызвало настоящий переполох: даже если сегодня он не может атаковать наши постквантовые алгоритмы, можно ли улучшить алгоритм Чена? Чтобы понять потенциальные улучшения, нужно понять, что на самом деле делает алгоритм на более высоком уровне. С алгоритмом Чена это сложно, поскольку он очень комплексный, гораздо более сложный, чем квантовый алгоритм Шора, который взламывает RSA. Поэтому экспертам потребовалось некоторое время, чтобы начать видеть ограничения подхода Чена, и фактически через десять дней они обнаружили фундаментальную ошибку в алгоритме: подход не работает. Кризис предотвращён.

Что из этого следует? Оптимистично: это обычное дело для криптографии, и решётки теперь в лучшей форме, поскольку один путь атаки оказался тупиковым. Реалистично: это напоминание, что у нас много яиц в корзине решёток. Как мы увидим позже, в настоящее время нет реальной альтернативы, которая работала бы везде.

Сторонники квантового распределения ключей (QKD) могут вставить, что QKD решает именно эту проблему, будучи безопасным благодаря законам природы. Что ж, к этому утверждению нужно добавить некоторые оговорки, но более фундаментально никто не понял, как масштабировать QKD за пределы точка-точка соединений, как мы утверждаем в этом посте блога.

Хорошо спекулировать о том, какая криптография может быть сломана совершенно новой атакой, но давайте не забывать о текущем вопросе: много криптографии точно будет сломано квантовыми компьютерами. Q-день приближается; вопрос в том, когда.

Если вы достаточно долго работаете в криптографии и безопасности или рядом с ними, то, вероятно, слышали, что "Q-день наступит через X лет" каждый год на протяжении последних нескольких лет. Это может создавать ощущение, что Q-день всегда "где-то в будущем" — пока мы не поместим такое утверждение в надлежащий контекст.

С 2019 года Институт глобальных рисков ежегодно проводит опрос среди экспертов, спрашивая, насколько вероятно, что RSA-2048 будет взломан в течение 5, 10, 15, 20 или 30 лет. Вот результаты за 2024 год, интервью для которого проводились до релиза Willow и прорыва Гидни.

^{Результаты опроса экспертов Института глобальных рисков за 2024 год о вероятности взлома RSA-2048 квантовым компьютером в разные сроки.}

Как показывает средняя колонка на этой диаграмме, значительно более половины опрошенных экспертов считали, что существует как минимум ~50% вероятность того, что квантовый компьютер взломает RSA-2048 в течение 15 лет. Давайте посмотрим исторические ответы из 2019, 2020, 2021, 2022 и 2023. Здесь мы построили график вероятности Q-дня в течение 15 лет (от времени интервью):

^{Исторические ответы в отчетах о временной шкале квантовой угрозы относительно шанса Q-дня в течение 15 лет.}

Это показывает, что ответы медленно смещаются к большей определённости, но с той ли скоростью, которую мы ожидаем? Имея шесть лет ответов, мы можем построить график, насколько последовательны прогнозы за год: совпадает ли 15-летняя оценка за 2019 год с 10-летней оценкой за 2024 год?

^{Исторические ответы в отчете о временной шкале квантовой угрозы за годы относительно даты Q-дня. Ось X — предполагаемый год Q-дня, а ось Y показывает долю опрошенных экспертов, которые считают, что это произойдет тогда с вероятностью не менее ~50% (слева) или 70% (справа).}

Если мы спросим экспертов, когда Q-день может наступить с примерно равными шансами (график слева), то они в основном продолжают говорить одно и то же на протяжении лет: да, может быть через 15 лет. Однако если мы настаиваем на большей определённости и спрашиваем о Q-дне с вероятностью >70% (график справа), то эксперты в основном последовательны на протяжении лет. Например: одна пятая часть считала 2034 годом как в интервью 2019, так и 2024 года.

Итак, если вы хотите получить последовательный ответ от эксперта, не спрашивайте его, когда Q-день может наступить, а когда он, вероятно, наступит. Теперь, конечно, весело гадать о Q-дне, но честный ответ заключается в том, что никто на самом деле не знает точно: слишком много неизвестных. И в конечном счёте дата Q-дня гораздо менее важна, чем сроки, установленные регуляторами.

Мы также можем посмотреть на временные рамки различных регуляторов. В 2022 году Агентство национальной безопасности (АНБ) выпустило свои рекомендации CNSA 2.0, в которых установлены сроки с 2030 по 2033 год для перехода на постквантовую криптографию. Также в 2022 году федеральное правительство США установило 2035 год в качестве цели полного перехода Соединенных Штатов, от которой новая администрация не отклонялась. В 2024 году Австралия установила 2030 год своим агрессивным сроком для перехода. В начале 2025 года UK NCSC соответствовал общему 2035 году как сроку для Соединенного Королевства. В середине 2025 года Европейский союз опубликовал свою дорожную карту со сроками 2030 и 2035 годов в зависимости от приложения.

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

Итак, когда квантовые компьютеры начнут создавать проблемы? Будь то 2034 или 2050 год, точно это будет слишком скоро. Огромный успех криптографии за пятьдесят лет означает, что она теперь повсюду вокруг нас, от посудомоечной машины до кардиостимулятора и спутника. Большинство обновлений будут легкими и естественно впишутся в жизненный цикл продукта, но будет длинный хвост сложных и дорогостоящих обновлений.

Теперь давайте взглянем на переход к постквантовой криптографии.

Чтобы помочь с расстановкой приоритетов, важно понимать, что существует большая разница в сложности, влиянии и срочности постквантовой миграции для различных видов криптографии, необходимых для создания безопасных соединений. Фактически, для большинства организаций будет две постквантовые миграции: согласование ключей и подписи/сертификаты. Давайте объясним это на примере создания безопасного соединения при посещении веб-сайта в браузере.

Криптографической рабочей лошадкой соединения является симметричный шифр, такой как AES-GCM. Это то, о чем вы подумали бы, думая о криптографии: обе стороны, в данном случае браузер и сервер, имеют общий ключ и шифруют/расшифровывают свои сообщения одним и тем же ключом. Если у вас нет этого ключа, вы не можете ничего прочитать или что-либо изменить.

Хорошая новость заключается в том, что симметричные шифры, такие как AES-GCM, уже постквантово безопасны. Существует распространенное заблуждение, что квантовый алгоритм Гровера требует от нас удвоения длины симметричных ключей. При более внимательном рассмотрении алгоритма становится ясно, что он не практичен. То, как NIST, Национальный институт стандартов и технологий США (который возглавляет стандартизацию постквантовой криптографии) определяет свои уровни постквантовой безопасности, очень показательно. Они определяют конкретный уровень безопасности, говоря, что схема должна быть такой же сложной для взлома с использованием как классического, так и квантового компьютера, как и существующий симметричный шифр, следующим образом:

^{Уровни безопасности NIST PQC, чем выше, тем сложнее взломать («безопаснее»). Примеры ML-DSA, SLH-DSA и ML-KEM рассмотрены ниже.}

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

Но если мы настаиваем на AES-256, кажется вполне логичным настаивать и на уровне 5 NIST PQC для криптографии с открытым ключом. Проблема в том, что криптография с открытым ключом масштабируется не очень хорошо. В зависимости от схемы, переход с уровня 1 на уровень 5 обычно более чем вдвое увеличивает использование данных и затраты на ЦП. Как мы увидим, развертывание постквантовых подписей на уровне 1 уже болезненно, а развертывание их на уровне 5 является изнурительным.

Но что более важно, у организаций есть только ограниченные ресурсы. Мы не хотели бы, чтобы организация prioritized обновление AES-128 ценой оставления определенно уязвимого для квантовых атак RSA.

Симметричных шифров самих по себе недостаточно: как мне узнать, какой ключ использовать при первом посещении веб-сайта? Браузер не может просто отправить случайный ключ, так как все, кто подслушивает, также увидят этот ключ. Вы могли бы подумать, что это невозможно, но есть clever math для решения этой проблемы, чтобы браузер и сервер могли договориться об общем ключе. Такая схема называется механизмом согласования ключей и выполняется в рукопожатии TLS. В 2024 году почти весь трафик защищен с помощью X25519, согласования ключей в стиле Диффи-Хеллмана, но его безопасность полностью нарушается алгоритмом Шора на квантовом компьютере. Таким образом, любая связь, защищенная сегодня с помощью Диффи-Хеллмана, при хранении может быть расшифрована в будущем квантовым компьютером.

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

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

Это достигается с помощью подписей. При посещении веб-сайта, скажем, cloudflare.com, веб-сервер представляет сертификат, подписанный центром сертификации (CA), который подтверждает, что открытый ключ в этом сертификате контролируется cloudflare.com. В свою очередь, веб-сервер подписывает рукопожатие и общий ключ, используя закрытый ключ, соответствующий открытому ключу в сертификате. Это позволяет клиенту быть уверенным, что он выполнил согласование ключей с cloudflare.com.

RSA и ECDSA — это обычно используемые традиционные схемы подписи сегодня. Опять же, алгоритм Шора легко справляется с ними, позволяя квантовому атакующему подделать любую подпись. Это означает, что злоумышленник с квантовым компьютером может выдать себя за (и выполнить MitM-атаку) любой веб-сайт, для которого мы принимаем не постквантовые сертификаты.

Эта атака может быть выполнена только после того, как квантовые компьютеры смогут взломать RSA/ECDSA. Это делает обновление схем подписи для TLS, на первый взгляд, менее срочным, поскольку нам нужно только, чтобы все мигрировали до наступления Q-дня. К сожалению, мы увидим, что миграция на постквантовые подписи значительно сложнее и потребует больше времени.

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

Физики Фейнман и Манин независимо предложили квантовые компьютеры около 1980 года. Прошло еще 14 лет, прежде чем Шор опубликовал свой алгоритм, атакующий RSA/ECC. Большая часть постквантовой криптографии предшествует знаменитому алгоритму Шора.

Существуют различные ветви постквантовой криптографии, из которых наиболее prominent являются решетчатые, хэш-базированные, многомерные, код-базированные и изогения-базированные. За исключением изогения-базированной криптографии, ни одна из них изначально не задумывалась как постквантовая криптография. Фактически, ранние код-базированные и хэш-базированные схемы являются современниками RSA, будучи предложенными в 1970-х годах и комфортно предшествуя публикации алгоритма Шора в 1994 году. Также первая многомерная схема 1988 года комфортно старше алгоритма Шора. Это приятное совпадение, что наиболее успешная ветвь, решетчатая криптография, является ближайшим современником Шора, будучи предложенной в 1996 году. Для сравнения, эллиптическая криптография, которая широко используется сегодня, была впервые предложена в 1985 году.

In the years after the publication of Shor’s algorithm, cryptographers took measure of the existing cryptography: what’s clearly broken, and what could be post-quantum secure? In 2006, the first annual International Workshop on Post-Quantum Cryptography took place. From that conference, an introductory text was prepared, which holds up rather well as an introduction to the field. A notable caveat is the demise of the Rainbow signature scheme. In that same year, 2006, the elliptic-curve key-agreement X25519 was proposed, which now secures the majority of Internet connections, either on its own or as a hybrid with the post-quantum ML-KEM-768. 

Ten years later, in 2016, NIST, the US National Institute of Standards and Technology, launched a public competition to standardize post-quantum cryptography. They used a similar open format as was used to standardize AES in 2001, and SHA3 in 2012. Anyone can participate by submitting schemes and evaluating the proposals. Cryptographers from all over the world submitted algorithms. To focus attention, the list of submissions were whittled down over three rounds. From the original 82, based on public feedback, eight made it into the final round. From those eight, in 2022, NIST chose to pick four to standardize first: one KEM (for key agreement) and three signature schemes.

The final standards for the first three have been published August 2024. FN-DSA is late and we’ll discuss that later.

ML-KEM is the only post-quantum key agreement standardised now, and despite some occasional difficulty with its larger key sizes, it’s mostly a drop-in upgrade.

The situation is rather different with the signatures: it’s quite telling that NIST chose to pursue standardising three already. And there are even more signatures set to be standardized in the future. The reason is that none of the proposed signatures are close to ideal. In short, they all have much larger keys and signatures than we’re used to.

From a security standpoint SLH-DSA is the most conservative choice, but also the worst performer. For public key and signature sizes, FN-DSA is as good as it gets for these three, but it is difficult to implement signing safely because of floating-point arithmetic. Due to FN-DSA’s limited applicability and design complexity, NIST chose to focus on the other three schemes first.

This leaves ML-DSA as the default pick. More in depth comparisons are included below.

Having NIST’s standards is not enough. It’s also required to standardize the way the new algorithms are used in higher level protocols. In many cases, such as key agreement in TLS, this can be as simple as assigning an identifier to the new algorithms. In other cases, such as DNSSEC, it requires a bit more thought. Many working groups at the IETF have been preparing for years for the arrival of NIST’s final standards, and we expected many protocol integrations to be finalized soon after, before the end of 2024. That was too optimistic: some are done, but many are not finished yet.

Let’s start with the good news and look at what is done.

• The hybrid TLS key agreement X25519MLKEM768 that combines X25519 and ML-KEM-768 (more about it later) is ready to use and is indeed quite widely deployed. Other protocols are likewise adopting ML-KEM in a hybrid mode of operation, such as IPsec, which is ready to go for simple setups. (For certain setups, there is a little wrinkle that still needs to be figured out. We’ll cover that in a future blog post.) It might be surprising that the corresponding RFCs have not been published yet. Registering a key agreement to TLS or IPsec does not require an RFC though. In both cases, the RFC is still being pursued to avoid confusion for those that would expect an RFC, and for TLS it’s required to mark the key agreement as recommended.

• For signatures, ML-DSA’s integration in X.509 certificates and TLS are good to go. The former is a freshly minted RFC, and the latter doesn’t require one.

Now, for the bad news. At the time of writing, October 2025, the IETF hasn’t locked down how to do hybrid certificates: certificates where both a post-quantum and a traditional signature scheme are combined. But it’s close. We hope this’ll be figured out early 2026.

But if it’s just assigning some identifiers, what’s the cause of the delay? Mostly it’s about choice. Let’s start with the choices that had to be made in ML-DSA.

The two major topics of discussion for ML-DSA certificates were prehashing and the private key format.

Prehashing is where one part of the system hashes the message, and another creates the final signatures. This is useful, if you don’t want to send a big file to an HSM to sign. Early drafts of ML-DSA  support prehashing with SHAKE256, but that was not obvious. In the final version of ML-DSA, NIST included two variants: regular ML-DSA, and an explicitly prehashed version, where you are allowed to choose any hash. Having different variants is not ideal, as users will have to choose which one to pick; not all software might support all variants; and testing/validation has to be done for all. It’s not controversial to want to pick just one variant, but the issue is which. After plenty of debate, regular ML-DSA was chosen.

The second matter is private key format. Because of the way that candidates are compared on performance benchmarks, it looks good for the original ML-DSA submission to cache some computation in the private key. This means that the private key is larger (several kilobytes) than it needs to be and requires more validation steps. It was suggested to cut the private key down to its bare essentials: just a 32-byte seed. For the final standard, NIST decided to allow both the seed and the original larger private key. This is not ideal: better stick to one of the two. In this case, the IETF wasn’t able to make a choice, and even added a third option: a pair of both the seed and expanded private key. Technically almost everyone agreed that seed is the superior choice, but the reason it wasn’t palatable is that some vendors already created keys for which they didn’t keep the seed around. Yes, we already have post-quantum legacy. It took almost a year to make these two choices.

Для определения гибридной схемы подписи ML-DSA требуется сделать гораздо больше выборов. С какой традиционной схемой комбинировать ML-DSA? Какие уровни безопасности использовать с обеих сторон. Затем нам также нужно сделать выбор для обеих схем: какой формат закрытого ключа использовать? Какой хеш использовать с ECDSA? У гибридных схем появляются свои новые вопросы. Разрешаем ли мы повторное использование ключей в гибридной схеме, и для этого хотим ли мы предотвратить атаки на удаление компонентов? Также возвращается вопрос предварительного хеширования с третьим вариантом: предварительное хеширование на уровне гибридной схемы.

Черновик от октября 2025 года для гибридных подписей ML-DSA содержит 18 вариантов, что меньше, чем 26 годом ранее. Опять же, все согласны, что это слишком много, но было трудно сократить список дальше. Чтобы помочь конечным пользователям выбрать, был добавлен сокращенный список, который начинался с трех вариантов и, конечно же, сам вырос до шести. Из них мы считаем, что MLDSA44-ECDSA-P256-SHA256 получит широкую поддержку и будет использоваться в Интернете.

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

Следующий шаг - программная поддержка. Не все экосистемы могут двигаться с одинаковой скоростью, но мы уже наблюдаем массовое внедрение постквантового согласования ключей для противодействия атаке "сохрани сейчас-расшифруй позже". В последних версиях всех основных браузеров, а также многих библиотек TLS и платформ, в частности OpenSSL, Go и последних ОС Apple, по умолчанию включен X25519MLKEM768. Мы ведем обзор здесь.

Опять же, для TLS существует большая разница между согласованием ключей и подписями. Для согласования ключей сервер и клиент могут независимо добавлять и включать поддержку постквантового согласования ключей. Как только поддержка будет включена с обеих сторон, TLS-согласование будет использовать постквантовое согласование ключей. Мы подробно рассматриваем TLS-согласование в этой записи блога. Если ваш продукт просто использует TLS, ваша проблема "сохрани сейчас-расшифруй сейчас" может быть решена простым обновлением программного обеспечения библиотеки TLS.

Постквантовые сертификаты TLS доставляют больше хлопот. Если вы не контролируете оба конца, вам нужно будет установить два сертификата: один постквантовый сертификат для новых клиентов и один традиционный для старых клиентов. Если вы еще не используете автоматическую выдачу сертификатов, это может быть хорошим поводом ознакомиться с этим. TLS позволяет клиенту сигнализировать о том, какие схемы подписи он поддерживает, чтобы сервер мог выбрать обслуживание постквантового сертификата только тем клиентам, которые его поддерживают. К сожалению, хотя почти все библиотеки TLS поддерживают настройку нескольких сертификатов, не все серверы предоставляют такую конфигурацию. Если они это делают, в большинстве случаев все равно потребуется изменение конфигурации. (Хотя, несомненно, caddy сделает это за вас.)

Говоря о постквантовых сертификатах: пройдет некоторое время, прежде чем центры сертификации (CA) смогут их выпускать. Их HSM сначала потребуют (аппаратную) поддержку, которую затем нужно будет проверить. Также форум CA/Browser должен одобрить использование новых алгоритмов. У корневых программ разные мнения относительно сроков. По слухам, мы слышим, что одна из корневых программ готовит пилотный проект по принятию однолетних сертификатов ML-DSA-87, возможно, даже до конца 2025 года. Для поддержки этого составляется бюллетень форума CA/Browser. Chrome, с другой стороны, предпочитает сначала решить проблему больших сертификатов. Для первых последователей проверки, вероятно, станут узким местом, поскольку после публикации стандартов NIST будет много заявок. Хотя мы увидим первые постквантовые сертификаты в 2026 году, маловероятно, что они будут широко доступны или доверяемы всеми браузерами до 2027 года.

Мы находимся в интересное переходное время, когда большой объем интернет-трафика защищен постквантовым согласованием ключей, но ни один публичный постквантовый сертификат не используется.

NIST еще не совсем закончил стандартизацию постквантовой криптографии. Продолжаются еще два постквантовых конкурса: четвертый раунд и "въездная рампа" для подписей.

NIST пока стандартизировал только одно постквантовое согласование ключей: ML-KEM. Они хотели бы иметь второе, резервное KEM, не основанное на решетках, на случай, если они окажутся слабее, чем ожидалось. Чтобы найти его, они расширили первоначальный конкурс четвертым раундом для выбора резервного KEM среди финалистов. В марте 2025 года HQC был выбран для стандартизации.

HQC работает намного хуже, чем ML-KEM, по каждому отдельному показателю. HQC-1, вариант с самым низким уровнем безопасности, требует 7 КБ данных при передаче. Это почти вдвое больше, чем 3 КБ, требуемые для ML-KEM-1024, варианта с самым высоким уровнем безопасности. Существует аналогичный разрыв в производительности ЦП. Также HQC хуже масштабируется с уровнем безопасности: в то время как ML-KEM-1024 стоит примерно вдвое дороже ML-KEM-512, самый высокий уровень безопасности HQC требует в три раза больше данных (21 КБ!) и более чем в четыре раза больше вычислений.

Что насчет безопасности? Для защиты от постепенно улучшающихся атак ML-KEM-768 имеет явное преимущество перед HQC-1: он работает намного лучше и имеет огромный запас безопасности на уровне 3 по сравнению с уровнем 1. Что насчет скачков? И ML-KEM, и HQC используют аналогичную алгебраическую структуру поверх обычных решеток и кодов соответственно: нельзя исключить, что прорыв там может быть применим к обоим. Теперь, даже без алгебраической структуры, коды и решетки кажутся связанными. Мы уже вступаем в область спекуляций: катастрофическая атака на решетки может не затронуть коды, но также не было бы удивительно, если бы затронула. В конце концов, RSA и ECC, которые более dissimilar, ломаются квантовыми компьютерами.

Возможно, все же есть смысл держать HQC на всякий случай. Здесь мы хотели бы поделиться anecdote из хаотичной недели, когда еще не было ясно, что квантовый алгоритм Чена против решеток содержит ошибку. На что заменить ML-KEM, если бы он был затронут? HQC кратко рассматривался, но было ясно, что адаптированный вариант ML-KEM все равно был бы намного производительнее.

Отступив назад: то, что мы ищем второе эффективное KEM, - это роскошная позиция. Если бы мне предоставили желание на новую постквантовую схему, я бы попросил не лучшее KEM, а лучшую схему подписи. Посмотрим, повезет ли мне.

В конце 2022 года, после объявления первых четырех выборов, NIST также объявил о новом конкурсе, названном «въездная рампа для подписей», чтобы найти дополнительные схемы подписи. У конкурса две цели. Первая - защита от криптоаналитических прорывов в области криптографии на решетках. NIST хотел бы стандартизировать подпись, которая работает лучше, чем SLH-DSA (как по размеру, так и по вычислениям), но не основана на решетках. Во-вторых, они ищут схему подписи, которая может хорошо работать в случаях использования, где текущий набор справляется плохо: мы подробно обсудим их далее в этом посте.

В июле 2023 года NIST опубликовал 40 представленных работ, которые они получили для первого раунда публичного обзора. Криптографическое сообщество принялось за работу, и, как это вполне обычно для первого раунда, многие схемы были взломаны в течение недели. К февралю 2024 года десять представленных работ были полностью взломаны, а несколько других были drastically ослаблены. Из оставшихся кандидатов в октябре 2024 года NIST отобрал 14 представленных работ для второго раунда.

Год назад мы написали запись в блоге, подробно освещающую эти 14 представленных работ. Если кратко: был достигнут удивительный прогресс в области постквантовых схем подписи. Мы кратко коснемся их позже и дадим некоторые обновления о достижениях с прошлого года. Стоит упомянуть, что, как и в основном постквантовом конкурсе, процесс отбора займет много лет. Маловероятно, что какая-либо из этих схем подписи "въездной рампы" будет стандартизирована до 2028 года — если они вообще не будут взломаны в первую очередь. Это означает, что хотя они очень желанны в будущем, мы не можем рассчитывать, что лучшие схемы подписи решат наши проблемы сегодня. Как пишет Эрик Рескорла, редактор TLS 1.3: «Вы идете на войну с теми алгоритмами, которые у вас есть, а не с теми, которые вы хотели бы иметь».

Имея это в виду, давайте посмотрим на прогресс развертываний.

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

Сначала о посквантовой части. ML-KEM был представлен под названием CRYSTALS-Kyber. Хотя это американский стандарт, его разработчики работают в промышленности и академических кругах Франции, Швейцарии, Нидерландов, Бельгии, Германии, Канады, Китая и США. Давайте посмотрим на его производительность.

Сегодня подавляющее большинство клиентов используют традиционное согласование ключей X25519. Сравним его с ML-KEM.

^{Сравнение размера и ЦП между X25519 и ML-KEM. Производительность значительно варьируется в зависимости от аппаратной платформы и ограничений реализации, и ее следует рассматривать лишь как приблизительный ориентир.}

ML-KEM-512, -768 и -1024 предназначены для обеспечения устойчивости к (квантовым) атакам, сопоставимой с AES-128, -192 и -256 соответственно. Даже на уровне AES-128 ML-KEM значительно больше X25519, требуя 800+768=1568 байт при передаче по сети, тогда как X25519 требует всего 64 байта.

С другой стороны, даже ML-KEM-1024, как правило, значительно быстрее X25519, хотя это может сильно варьироваться в зависимости от вашей платформы и реализации.

Мы пока не используем это ускорение. Как и многие другие первопроходцы, мы предпочитаем перестраховаться и развернуть гибридное согласование ключей, комбинирующее X25519 и ML-KEM-768. Эта комбинация может удивить вас по двум причинам.

1. Зачем комбинировать X25519 («128 бит безопасности») с ML-KEM-768 («192 бита безопасности»)?

2. Зачем вообще использовать не посквантовый X25519?

Кажущееся несоответствие уровней безопасности — это страховка от улучшений криптоанализа в решеточной криптографии. Существует большое доверие к (не посквантовой) безопасности X25519: соответствие AES-128 более чем достаточно. Хотя сегодня мы уверены в безопасности ML-KEM-512, в ближайшие десятилетия криптоанализ может улучшиться. Поэтому мы пока хотим сохранить запас.

Включение X25519 имеет две причины. Во-первых, всегда есть малая вероятность, что прорыв сделает все варианты ML-KEM небезопасными. В этом случае X25519 все еще обеспечивает не посквантовую безопасность, и наша миграция на посквантовые технологии не ухудшила ситуацию.

Более важно то, что мы беспокоимся не только об атаках на алгоритм, но и на реализацию. Примечательный пример, когда мы избежали проблемы, — это KyberSlash, атака по времени, которая затронула многие реализации Kyber (более ранней версии ML-KEM), включая нашу собственную. К счастью, KyberSlash не затрагивает Kyber в том виде, в каком он используется в TLS. Подобная ошибка реализации, которая действительно повлияла бы на TLS, вероятно, потребовала бы активного злоумышленника. В этом случае вероятной целью атаки была бы не расшифровка данных десятилетия спустя, а кража cookie или другого токена, либо внедрение полезной нагрузки. Включение X25519 предотвращает такую атаку.

Итак, насколько хорошо ML-KEM-768 и X25519 вместе работают на практике?

Хорошо осознавая потенциальные проблемы совместимости и производительности, Google начал первый эксперимент с посквантовой криптографией еще в 2016 году, в том же году, когда NIST начал свой конкурс. За этим последовал второй, более масштабный совместный эксперимент Cloudflare и Google в 2018 году. Мы протестировали два разных гибридных посквантовых согласования ключей: CECPQ2, который представляет собой комбинацию решеточного NTRU-HRSS и X25519, и CECPQ2b, комбинацию изогениевого SIKE и снова X25519. NTRU-HRSS очень похож на ML-KEM по размеру, но вычислительно несколько более затратен на стороне клиента. SIKE, с другой стороны, имеет очень маленькие ключи, очень требователен к вычислениям и был полностью взломан в 2022 году. Что касается времени подтверждения TLS, X25519+NTRU-HRSS показал себя очень хорошо.

К сожалению, небольшая, но значительная часть клиентов столкнулась с разрывами соединений при использовании NTRU-HRSS. Причина: размер ключевых долей NTRU-HRSS. В прошлом, при создании TLS-соединения, первое сообщение, отправляемое клиентом, так называемое ClientHello, почти всегда умещалось в один сетевой пакет. Спецификация TLS допускает более крупное ClientHello, однако никто этим по-настоящему не пользовался. Таким образом, оссификация протокола снова проявляется, поскольку существуют некоторые промежуточные устройства, балансировщики нагрузки и другое программное обеспечение, которые молчаливо предполагают, что ClientHello всегда помещается в один пакет.

В последующие годы мы продолжали экспериментировать с PQ, переключившись на Kyber в 2022 году и на ML-KEM в 2024 году. Chrome проделал большую работу, обращаясь к поставщикам, чьи продукты были несовместимы. Если бы не эти проблемы совместимости, мы бы, вероятно, увидели, как Chrome внедряет посквантовое согласование ключей на пять лет раньше. Потребовалось до марта 2024 года, прежде чем Chrome почувствовал себя достаточно уверенно, чтобы включить посквантовое согласование ключей по умолчанию на Desktop. После этого многие другие клиенты и все основные браузеры присоединились к Chrome во включении посквантового согласования ключей по умолчанию. Неполная хронология:

Примечательно, что существует разрыв между включением PQ в Chrome на Desktop и на Android. Хотя ML-KEM не оказывает большого влияния на производительность, как видно из графиков, он, безусловно, не пренебрежимо мал, особенно на длинном хвосте более медленных соединений, более распространенных на мобильных устройствах, и потребовалось больше размышлений, чтобы продолжить.

Но теперь мы наконец здесь: более 50% (и растет!) человеческого трафика защищено от атак «сохрани-сейчас/расшифруй-позже», что делает посквантовое согласование ключей новым базовым уровнем безопасности для Веба.

Браузеры — это одна сторона уравнения, а как насчет серверов?

Еще в 2022 году мы включили посквантовое согласование ключей на стороне сервера практически для всех клиентов. Google сделал то же самое для большинства своих серверов (кроме GCP) в 2023 году. С тех пор многие последовали их примеру. Ян Шауманн регулярно публикует результаты сканирования топ-100k доменов. В своем посте за сентябрь 2025 года он сообщает, что 39% теперь поддерживают PQ, по сравнению с 28% всего шесть месяцев назад. В его исследовании мы видим, что поддержка развертывается не только на крупных поставщиках услуг, таких как Amazon, Fastly, Squarespace, Google и Microsoft, но и на отдельных самохостинговых серверах, добавляющих поддержку, размещенных на Hetzner и OVHcloud.

Это общедоступный веб. А как насчет серверов за сервисом вроде Cloudflare?

В сентябре 2023 мы добавили поддержку для наших клиентов, позволяющую включить посквантовое согласование ключей на соединениях от Cloudflare к их источникам (origins). Это соединение (3) на следующей диаграмме:

^{Типичный поток соединения, когда посетитель запрашивает некэшированную страницу.}

В 2023 году только 0,5% источников поддерживали постквантовое согласование ключей. В течение 2024 года ситуация мало изменилась. В этом, 2025 году, мы видим, что поддержка медленно растёт по мере внедрения программного обеспечения, и сейчас мы достигли 3,7%.

^{Доля источников, поддерживающих постквантовое согласование ключей X25519MLKEM768.}

3,7% не звучит впечатляюще по сравнению с предыдущими 50% и 39% для клиентов и публичных серверов соответственно, но это не то, чем можно пренебрегать. Среди источников гораздо больше разнообразия, чем среди клиентов: гораздо большему количеству людей нужно что-то сделать, чтобы эта цифра выросла. Но это всё же более чем семикратный рост, и давайте не забывать, что в 2024 году мы праздновали достижение 1,8% поддержки со стороны клиентов. Для клиентов обновление источников не всегда является простой задачей. Означает ли это, что они лишаются постквантовой безопасности? Нет, не обязательно: вы можете защитить соединение между Cloudflare и вашим источником, настроив Cloudflare Tunnel в качестве сайдкара для вашего источника.

Поддержка — это хорошо, но, как мы видели на примере экспериментов с браузерами, протокольная осификация вызывает большие опасения. Как это выглядит с источниками? Что ж, это зависит от обстоятельств.

Существует два способа включить постквантовое согласование ключей: быстрый способ и медленный, но безопасный способ. В обоих случаях, если источник не поддерживает постквантовые технологии, он безопасно откатится к традиционному согласованию ключей. Мы объясняем детали в этом посте блога, но вкратце: при быстром способе мы отправляем постквантовые ключи сразу, а при безопасном способе мы откладываем это на один круговой обход, используя HelloRetryRequest. Все основные браузеры используют быстрый способ.

Мы регулярно сканируем все источники, чтобы увидеть, что они поддерживают. Хорошая новость заключается в том, что все источники поддерживали безопасный, но медленный метод. Быстрый метод показал себя не так хорошо, поскольку мы обнаружили, что 0,05% соединений нарушаются. Это слишком высокий показатель, чтобы включать быстрый метод по умолчанию. Мы включили PQ для источников, использующих более безопасный метод, по умолчанию для всех некорпоративных клиентов, а корпоративные клиенты могут присоединиться.

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

До сих пор все соединения, о которых мы говорили, были между Cloudflare и внешними сторонами. Также существует множество внутренних соединений внутри Cloudflare (отмечены цифрой 2 на двух приведенных выше диаграммах). В 2023 году мы сделали большой рывок, чтобы перевести наши внутренние соединения на постквантовое согласование ключей. По сравнению со всеми другими постквантовыми усилиями, которые мы предпринимаем, эта работа была, безусловно, самой масштабной: мы попросили каждую инженерную команду в компании остановить текущую работу; оценить данные и соединения, которые защищают их продукты; и перевести их на постквантовое согласование ключей. В большинстве случаев обновление было простым. Фактически, многие команды уже обновились, установив обновления программного обеспечения. Тем не менее, выяснение того, что вы уже всё сделали, может занять довольно много времени! С положительной стороны, мы не увидели никаких проблем с производительностью или осификацией в ходе этой работы.

Мы обновили большинство внутренних соединений, но остаётся длинный хвост, над которым мы продолжаем работать. Самое важное соединение, которое нам не удалось обновить в 2023 году, — это соединение между клиентом WARP и Cloudflare. В сентябре 2025 года мы обновили его, перейдя с Wireguard на QUIC.

Как мы видели, развёртывание постквантового согласования ключей, несмотря на первоначальные проблемы с протокольной осификацией, было достаточно straightforward. В подавляющем большинстве случаев это незаметное обновление программного обеспечения. И при 50% внедрении (и росте) это новый базовый уровень безопасности для Интернета.

Давайте перейдём ко второй, более сложной миграции.

Теперь мы обратим наше внимание на обновление подписей, используемых в Интернете.

Мы написали большой глубокий обзор в области схем постквантовых подписей в ноябре прошлого, 2024 года. Большая часть этого всё ещё актуальна, но были некоторые захватывающие developments. Здесь мы просто рассмотрим некоторые highlights и некоторые exciting updates прошлого года.

Давайте начнём с оценки постквантовых подписей, которые у нас есть сегодня на уровне безопасности AES-128: ML-DSA-44 и два варианта SLH-DSA. Мы используем ML-DSA-44 в качестве базового уровня, поскольку это схема, которая изначально получит наиболее широкое распространение. Для сравнения мы также включаем почтенный Ed25519 и широко используемый сегодня RSA-2048, а также FN-DSA-512, который скоро будет стандартизирован, и выборку из девяти перспективных схем подписей для TLS из "signatures onramp".

^{Сравнение различных схем подписей на уровне безопасности AES-128. Время ЦП значительно варьируется в зависимости от платформы и ограничений реализации и должно рассматриваться лишь как грубый ориентир. ⚠️ Время подписания FN-DSA при использовании быстрой, но опасной арифметики с плавающей запятой — см. предупреждение ниже. ⚠️ Подписание SQISign не защищено от временных атак по сторонним каналам.}

Сразу становится ясно, что ни одна из схем постквантовых подписей даже близко не является прямой заменой для Ed25519 (который сравним с ECDSA P-256), поскольку большинство подписей просто намного больше. Исключениями являются SQISign, MAYO, SNOVA и UOV из "onramp", но они далеки от идеала. MAYO, SNOVA и UOV имеют большие открытые ключи, а SQISign требует огромных вычислительных затрат.

Забегая немного вперёд: лучшим из первого конкурса, кажется, является FN-DSA-512. Подписи и открытый ключ FN-DSA-512 вместе составляют всего 1563 байта, со сравнительно разумным временем подписания. Однако у FN-DSA есть ахиллесова пята — для приемлемой производительности подписания требуется быстрая арифметика с плавающей запятой. Без неё подписание происходит примерно в 20 раз медленнее. Но скорости недостаточно, поскольку арифметика с плавающей запятой должна выполняться за постоянное время — без этого закрытый ключ FN-DSA можно восстановить, измеряя время создания подписи. Создание безопасных реализаций FN-DSA оказалось довольно сложной задачей, что делает FN-DSA опасной, когда подписи создаются на лету, например, при TLS-рукопожатии. Важно подчеркнуть, что это влияет только на подписание. Проверка FN-DSA не требует арифметики с плавающей запятой (и во время проверки закрытого ключа для утечки всё равно не будет).

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

Большинство из них предназначены для цепочки сертификатов: ЦС подписывает промежуточный сертификат, который подписывает листовой сертификат, который, в свою очередь, подписывает TLS-транскрипт, чтобы подтвердить подлинность сервера. Если вы ведёте подсчёт: нам всё ещё не хватает двух подписей.

Они предназначены для SCT, требуемых для прозрачности сертификатов. Прозрачность сертификатов (CT) является ключевой, но менее известной частью Web PKI, экосистемы, защищающей соединения браузера. Её цель — публичное логирование каждого выданного сертификата, чтобы неправомерные выдачи можно было обнаружить постфактум. Это система, стоящая за crt.sh и Cloudflare Radar. CT совсем недавно вновь продемонстрировала свою ценность, выявив подложный сертификат для 1.1.1.1.

Прозрачность сертификатов работает за счёт того, что независимые стороны ведут журналы CT. Прежде чем выпустить сертификат, ЦС должен сначала отправить его как минимум в два разных журнала CT. SCT — это подпись журнала CT, которая выступает в качестве доказательства, квитанции о том, что сертификат был залогирован.

Есть два аспекта использования подписи, которые стоит выделить: включается ли открытый ключ вместе с подписью и является ли подпись онлайн или офлайн.

Для SCT и подписи корневого сертификата на промежуточном открытый ключ не передаётся during handshake. Таким образом, для них особенно хорошо подошла бы схема подписи с меньшими подписями, но большими открытыми ключами, такая как MAYO, SNOVA или UOV. Для других подписей открытый ключ включается, и важнее минимизировать размеры комбинации открытого ключа и подписи.

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

Собирать вместе различные схемы подписи — это интересная головоломка, но у этого есть и недостатки. Использование нескольких различных схем увеличивает поверхность атаки, потому что алгоритмическая или реализационная уязвимость в одной компрометирует всю систему. Кроме того, всей экосистеме необходимо реализовывать и оптимизировать несколько алгоритмов, что является значительным бременем.

Итак, какие разумные комбинации стоит попробовать?

Имея на руках текущие проекты стандартов, у нас не так много вариантов.

Если мы просто переключимся на ML-DSA-44 для всех подписей, мы добавим 15 КБ данных, которые нужно передать с сервера на клиент во время подтверждения соединения TLS. Это много? Вероятно. Мы вернемся к этому позже.

Если мы немного подождем и заменим все подписи, кроме сигнатуры подтверждения соединения, на FN-DSA-512, то мы добавим всего 7 КБ. Это намного лучше, но я должен повторить, что безопасно реализовать подписание FN-DSA-512 без временных побочных каналов сложно, и есть большой риск выстрелить себе в ногу, если не быть осторожным. Другой способ выстрелить себе в ногу сегодня — это использовать stateful хеш-подписи, как мы объясняем здесь. В целом, FN-DSA-512 и stateful хеш-подписи соблазняют нас схожим и очевидным преимуществом в производительности перед ML-DSA-44, но их сложно безопасно использовать.

В NIST было подано несколько перспективных новых схем подписи.

Если смотреть только на размеры, SQISign I — явный победитель, даже обгоняя RSA-2048. К сожалению, требуемые для подписания и, что критически важно, для проверки вычисления слишком велики. SQISign находится в худшем положении, чем FN-DSA, с точки зрения безопасности реализации: алгоритм очень сложен, и неясно, как выполнять подписание за постоянное время. Для нишевых приложений SQISign может быть полезен, но для широкого внедрения время проверки должно значительно улучшиться, даже если для этого потребуется сигнатура большего размера. За последние несколько лет был достигнут удивительный прогресс в улучшении времени проверки, упрощении алгоритма и безопасности реализации для (вариантов) SQISign. Они еще не достигли цели, но разрыв сократился гораздо сильнее, чем мы ожидали. Если темпы улучшений сохранятся, то будущая версия SQISign вполне может стать жизнеспособной для TLS.

Одним консервативным претендентом является UOV (Unbalanced Oil and Vinegar). Это старая многомерная схема с большим открытым ключом (66,5 КБ), но маленькими сигнатурами (96 байт). На протяжении десятилетий было много попыток добавить некоторую структуру в открытые ключи UOV, чтобы добиться лучшего баланса между размером открытого ключа и сигнатуры. К сожалению, многие из этих так называемых структурированных многомерных схем, включая Rainbow и GeMMS, были сломаны сокрушительно "с помощью ноутбука за выходные". MAYO и SNOVA, к которым мы скоро перейдем, — это последние попытки создать структурированные многомерные схемы. Сам UOV в основном остался невредимым. Неожиданно в 2025 году Ларс Ран обнаружил совершенно новую атаку "wedges" на UOV. Она не сильно затронула UOV, хотя SNOVA и MAYO пострадали сильнее. Примечательно в этой атаке то, что она основана на относительно простой идее: удивительно, что ее не нашли раньше. Теперь, возвращаясь к производительности: если мы объединим UOV для корневого сертификата и SCT с ML-DSA-44 для остальных, мы получим всего 10 КБ — близко к FN-DSA-512.

Теперь перейдем к главному событию:

Глядя на текущий список, MAYO и особенно SNOVA выглядят великолепно с точки зрения производительности. В прошлом году SNOVA и MAYO были ближе по производительности, но с тех пор они довольно сильно разошлись.

MAYO разработана криптографом, который взломал Rainbow. Будучи структурированной многомерной схемой, ее безопасность требует тщательного изучения, но ее полезность (при условии, что она не сломана) очень привлекательна. MAYO позволяет осуществлять детальный баланс между размером сигнатуры и открытого ключа. Для подачи заявки, чтобы упростить задачу, авторы предложили два конкретных варианта: MAYO_one со сбалансированными размерами сигнатуры (454 байта) и открытого ключа (1,4 КБ), и MAYO_two с сигнатурами размером 216 байт, сохраняя при этом открытый ключ управляемым (4,3 КБ). Время проверки отличное, в то время как время подписания несколько медленнее, чем у ECDSA, но намного лучше, чем у RSA. Комбинируя оба варианта очевидным образом, мы получаем всего 4,3 КБ. Эти цифры немного выше, чем в прошлом году, поскольку MAYO снова немного скорректировала свои параметры в свете новых обнаруженных атак.

За время конкурса SNOVA пострадала от атак сильнее, чем MAYO. Ответ SNOVA был более агрессивным: вместо простой корректировки параметров они также внесли более серьезные изменения во внутреннюю структуру схемы, чтобы противостоять атакам и заодно получить прирост производительности. Комбинируя SNOVA_(37,17,16,2) и SNOVA_(24,5,23,4) очевидным образом, мы получаем потрясающие 2,1 КБ.

Мы видим формирующееся противостояние между рискованной, но гораздо более компактной SNOVA и консервативной, но более медленной MAYO. Если смотреть шире, обе имеют очень желанную производительность, и обе пока слишком рискованны для развертывания. Новая атака Рана "wedges" — пример того, что область многомерного криптоанализа все еще хранит сюрпризы и требует больше внимания и времени. Слишком рано выбирать победителя между SNOVA и MAYO: пусть они продолжают соревноваться. Даже если они окажутся безопасными, маловероятно, что какая-либо из них будет стандартизирована к 2029 году, а значит, мы не можем полагаться на них для первоначального перехода на постквантовую аутентификацию.

Возвращаясь назад, действительно ли 15 КБ для ML-DSA-44 так уж плохи?

В среднем с Cloudflare устанавливается около 18 миллионов TLS-соединений в секунду. Обновление каждого из них до ML-DSA потребовало бы 2,1 Тбит/с, что составляет 0,5% от нашей текущей общей пропускной способности сети. Пока проблем нет. Вопрос в том, как эти лишние байты влияют на производительность.

Замена на ML-DSA-44 потребует дополнительных 15 КБ. Это много по сравнению с типичным подтверждением соединения сегодня, но не много по сравнению с jаvascript и изображениями, загружаемыми на многих веб-страницах. Ключевой момент заключается в том, что это изменение затрагивает каждое отдельное TLS-соединение, независимо от того, используется ли оно для перегруженного веб-сайта или для критичного ко времени API-вызова. Кроме того, дело не только в том, чтобы подождать немного дольше. Если у вас нестабильная сотовая связь, эти лишние данные могут стать разницей между возможностью загрузить страницу и таймаутом соединения. (К слову о раздувании: многие приложения выполняют удивительно большое количество подтверждений соединения TLS).

Так же, как и с согласованием ключей, производительность — не единственная наша забота: мы также хотим, чтобы соединение вообще устанавливалось. Еще в 2021 году мы провели эксперимент, искусственно увеличивая цепочку сертификатов, чтобы смоделировать большие постквантовые сертификаты. Мы резюмируем результат здесь. Один ключевой вывод заключается в том, что некоторым клиентам или промежуточным устройствам не нравятся цепочки сертификатов размером более 10 КБ. Это проблематично для стратегии миграции с одним сертификатом. В этом подходе сервер устанавливает один традиционный сертификат, который содержит отдельный постквантовый сертификат в так называемом некритичном расширении. Клиент, который не поддерживает постквантовые сертификаты, проигнорирует расширение. При таком подходе установка единственного сертификата немедленно нарушит работу всех клиентов с проблемами совместимости, что делает его неприемлемым. С точки зрения производительности также наблюдается резкое падение при 10 КБ из-за начального окна перегрузки.

Слишком ли много 9 КБ? Замедление времени подтверждения соединения TLS составило бы приблизительно 15%. Мы посчитали, что последнее работоспособно, но далеко от идеала: такое замедление заметно, и люди могут откладывать развертывание постквантовых сертификатов, пока не станет слишком поздно.

Chrome более осторожен и установил 10% в качестве целевого показателя максимальной регрессии времени TLS-рукопожатия. Они сообщают, что развертывание постквантового согласования ключей уже привело к замедлению времени TLS-рукопожатия на 4% из-за дополнительных 1,1 КБ от сервера к клиенту и 1,2 КБ от клиента к серверу. Это замедление пропорционально больше, чем 15%, которые мы обнаружили для 9 КБ, но это можно объяснить более медленными скоростями загрузки по сравнению со скоростями скачивания.

Была критика в отношении сосредоточенности на времени TLS-рукопожатия. Один аргумент заключается в том, что возобновление сессии устраняет необходимость повторной отправки сертификатов. Второй аргумент — что данные, необходимые для посещения типичного веб-сайта, затмевают дополнительные байты для постквантовых сертификатов. Один пример — это публикация 2024 года, где исследователи Amazon смоделировали влияние крупных постквантовых сертификатов на TLS-соединения с большим объемом данных. Они утверждают, что типичные соединения передают несколько запросов и сотни килобайт, и для них замедление TLS-рукопожатия становится незначительным.

Но типичны ли возобновление сессии и сотни килобайт за соединение? Мы хотели бы поделиться тем, что видим. Мы фокусируемся на QUIC-соединениях, которые, вероятно, инициируются браузерами или подобными браузерам клиентами. Из всех QUIC-соединений с Cloudflare, которые передают хотя бы один HTTP-запрос, 27% являются возобновлениями, что означает повторное использование ключевого материала из предыдущего TLS-соединения, избегая необходимости передачи сертификатов. Медианное количество байт, переданных от сервера к клиенту по возобновленному QUIC-соединению, составляет 4,4 КБ, тогда как среднее значение — 259 КБ. Для невозобновленных соединений медиана составляет 8,1 КБ, а среднее — 583 КБ. Эта огромная разница между медианой и средним значением указывает на то, что небольшая доля соединений с большим объемом данных искажает среднее значение. Фактически, только 15,5% всех QUIC-соединений передают более 100 КБ.

Медианная цепочка сертификатов сегодня (со сжатием) составляет 3,2 КБ. Это означает, что почти 40% всех данных, передаваемых от сервера к клиенту в более чем половине невозобновленных QUIC-соединений, предназначены только для сертификатов, и это только ухудшается с постквантовыми алгоритмами. Для большинства QUIC-соединений использование ML-DSA-44 в качестве замены классических подписей более чем удвоило бы количество передаваемых байт за время жизни соединения.

Звучит довольно плохо, если подавляющее большинство данных, передаваемых для типичного соединения, предназначено только для постквантовых сертификатов. Это все еще лишь приблизительный показатель того, что действительно важно: влияние на метрики, значимые для конечного пользователя, такие как опыт просмотра (например, наибольшая содержательная отрисовка) и объем данных, которые эти сертификаты занимают из ежемесячного лимита данных пользователя. Мы продолжим исследовать и лучше понимать это влияние.

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

Мы исследуем различные идеи по сокращению количества подписей, в порядке возрастания амбиций: исключение промежуточных сертификатов; KEMTLS; и Сертификаты на основе Дерева Меркла. Мы подробно освещали их в прошлом году. Наибольший прогресс достигнут в последнем: Сертификаты на основе Дерева Меркла (MTC). В этом предложении в обычном случае все подписи, кроме подписи рукопожатия, заменяются коротким доказательством Дерева Меркла <800 байт. Это вполне может позволить постквантовую аутентификацию, которая на самом деле быстрее, чем использование традиционных сертификатов сегодня! Вместе с Chrome мы попробуем это к концу года: читайте об этом в этом блоге.

Несмотря на свою длину, в этом посте в блоге мы лишь вкратце затронули миграцию TLS. И даже TLS мы не покрыли полностью, так как не обсудили Зашифрованный ClientHello (мы о нем не забыли). Хотя TLS важен, это не единственный ключевой протокол для безопасности Интернета. Мы хотим кратко упомянуть несколько других проблем, но не можем вдаваться в подробности. Одна конкретная проблема — это DNSSEC, который отвечает за безопасное разрешение доменных имен.

Хотя согласование ключей и подписи являются наиболее широко используемыми криптографическими примитивами, за последние несколько лет мы наблюдали внедрение более эзотерической криптографии для обслуживания более продвинутых случаев использования, таких как не связываемые токены с Privacy Pass / PAT, анонимные учетные данные и шифрование на основе атрибутов, чтобы назвать несколько. Для большинства этих продвинутых криптографических схем пока не существует известных практических постквантовых альтернатив. Хотя, к нашей радости, были достигнуты большие успехи в постквантовых анонимных учетных данных.

Подводя итог, есть две основные постквантовые миграции, за которыми стоит следить: согласование ключей и сертификаты.

Мы рекомендуем переходить на постквантовое согласование ключей для противодействия атакам типа «сохранить сейчас — расшифровать позже», что требует только обновления программного обеспечения с обеих сторон. Это означает, что при быстром внедрении (мы ведем список) X25519MLKEM768 в программное обеспечение и сервисы вы, возможно, уже защищены от атак «сохранить сейчас — расшифровать позже»! На Cloudflare Radar вы можете проверить, поддерживает ли ваш браузер X25519MLKEM768; если вы используете Firefox, есть расширение для проверки поддержки веб-сайтов во время посещения; вы можете просканировать, поддерживает ли ваш веб-сайт это, здесь; и вы можете использовать Wireshark для проверки в трафике.

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

Поскольку выяснение что делать составляет основную часть работы, возможно, заманчиво выделить это в качестве первого этапа: сначала создать подробную опись; так называемую криптографическую ведомость материалов (CBOM). Не позволяйте инвентаризации стать самоцелью: нам нужно держать фокус на главном. Большинство случаев просты: если вы выяснили, что нужно сделать для миграции в одном случае, не ждите и не переключайте контекст, а просто сделайте это. Это не значит, что это будет быстро: это марафон, а не спринт, но вы удивитесь, сколько ground можно покрыть, просто начав.

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

Если вы беспокоитесь об окостенении протокола, нет причин ждать: окончательные постквантовые стандарты не будут сильно отличаться от черновика. Вы можете тестировать с предварительными реализациями (или большими фиктивными сертификатами) уже сегодня.

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