X25519MLKEM768 или X25519 — это решение об обмене ключами, которое сегодня принимается в каждом рукопожатии TLS 1.3. X25519 сам по себе быстр и компактен, но не устоит перед квантовым компьютером, а значит, записанный сейчас трафик можно будет расшифровать позже. X25519MLKEM768 выполняет X25519 и ML-KEM-768 вместе, поэтому сеанс остаётся конфиденциальным, пока не взломаны оба.
Коротко о главном
| X25519 | X25519MLKEM768 | |
|---|---|---|
| Поддерживаемая группа TLS (supported group) | x25519, 29 (0x001D) | X25519MLKEM768, 4588 (0x11EC), рекомендована IANA (Recommended) |
| Спецификация | RFC 7748, RFC 9846 | RFC 10024 (2026), общая схема — RFC 9954 |
| Компоненты | X25519 | ML-KEM-768 (FIPS 203) и X25519 |
| Key share клиента | 32 байта | 1 216 байт (1 184 — ключ инкапсуляции ML-KEM, плюс 32) |
| Key share сервера | 32 байта | 1 120 байт (1 088 — шифртекст ML-KEM, плюс 32) |
| Общий секрет для схемы выработки ключей (key schedule) | 32 байта | 64 байта (сначала секрет ML-KEM, затем X25519) |
| Стойкость к квантовым атакам | Нет | Да, пока ML-KEM-768 не взломан |
| Классическая стойкость | X25519 | Не ниже X25519, даже если бы ML-KEM был взломан |
| CPU на рукопожатие, OpenSSL 3.6.5 | около 52 000 операций X25519 в секунду | около 19 000–24 000 генераций ключа, инкапсуляций или декапсуляций в секунду |
| ClientHello в замере ниже | 306 байт | 1 484 байта |
| ServerHello в замере ниже | 122 байта | 1 210 байт |
Пропускная способность — по данным openssl speed на одном ядре Apple M4 Max; размеры рукопожатий — из захвата ниже.
Почему гибрид нужен уже сейчас
Обмен ключами уязвим для атак «собери сейчас, расшифруй потом»: противник записывает зашифрованные сеансы сегодня и расшифровывает их, когда появится криптографически значимый квантовый компьютер, восстанавливая ключи сеансов из записанного обмена X25519. Прямая секретность здесь не помогает, потому что каждый записанный обмен можно взломать по отдельности. Всё, чья конфиденциальность должна пережить появление такого компьютера, уже под угрозой; поэтому на постквантовые алгоритмы первым перешёл обмен ключами, а подписи могут подождать дольше.
Гибридная схема страхует и в обратную сторону. ML-KEM стандартизирован в августе 2024 года и молод по сравнению с X25519, так что нельзя исключать ни математического взлома, ни ошибки в реализации. X25519MLKEM768 конкатенирует оба общих секрета и подаёт результат в схему выработки ключей TLS, поэтому атакующему придётся взломать оба. Для этой группы RFC 10024 ставит key share и секрет ML-KEM первыми, в отличие от гибридов на кривых NIST (SecP256r1MLKEM768, 0x11EB, и SecP384r1MLKEM1024, 0x11ED), в которых первым идёт ECDH.
Что меняется в трафике
Клиент отправляет key share длиной 1 216 байт вместо 32 байт, поэтому типичный ClientHello вырастает примерно с 300 байт до 1,5 КБ и вместе со всеми остальными расширениями браузера уже не помещается в один сетевой пакет. Сервер отвечает key share длиной 1 120 байт. Захват реального рукопожатия с Cloudflare в OpenSSL 3.6.5 показывает разницу:
echo | openssl s_client -connect cloudflare.com:443 -servername cloudflare.com -groups X25519MLKEM768 -brief 2>&1 | grep -E "Protocol|group"
echo | openssl s_client -connect cloudflare.com:443 -servername cloudflare.com -groups X25519MLKEM768 -msg 2>&1 | grep -E "ClientHello|ServerHello"
echo | openssl s_client -connect cloudflare.com:443 -servername cloudflare.com -groups X25519 -msg 2>&1 | grep -E "ClientHello|ServerHello"
Protocol version: TLSv1.3
Negotiated TLS1.3 group: X25519MLKEM768
>>> TLS 1.3, Handshake [length 05cc], ClientHello
<<< TLS 1.3, Handshake [length 04ba], ServerHello
>>> TLS 1.3, Handshake [length 0132], ClientHello
<<< TLS 1.3, Handshake [length 007a], ServerHello
Это 1 484 против 306 байт для ClientHello и 1 210 против 122 для ServerHello. Увеличенные ClientHello выявили ошибки в серверах и промежуточных устройствах, которые рассчитывали, что сообщение приходит за одно чтение TCP или в одном пакете: когда Chrome в версии 124 (2024 год) включил гибридные key share с Kyber по умолчанию, несколько межсетевых экранов и прокси пришлось исправлять; этот класс проблем описан на tldr.fail. Cloudflare и Google сообщили, что лишние байты добавляют несколько процентов к медианной задержке рукопожатия, а это гораздо меньше, чем выигрыш от циклов приёма-передачи, которые экономит сам TLS 1.3.
Статус внедрения
- Браузеры: Chrome и Edge предлагают X25519MLKEM768 по умолчанию с версии 131 (ноябрь 2024 года), Firefox — с версии 132 на десктопе, Safari и системный TLS Apple — с iOS 26 и macOS 26 (2025 год). Предстандартная группа
X25519Kyber768Draft00(0x6399), которую они использовали раньше, объявлена устаревшей. - Библиотеки: OpenSSL 3.5 (апрель 2025 года) по умолчанию отправляет key share для X25519MLKEM768 и для X25519; Go 1.24 включает гибрид по умолчанию в
crypto/tls; JDK 27 (сентябрь 2026 года, JEP 527) по умолчанию предлагает его первым; BoringSSL, rustls и NSS его поддерживают. - Серверы и CDN: Cloudflare, Google и другие крупные провайдеры согласуют его с клиентами, которые его поддерживают; nginx, Apache и HAProxy получают его от OpenSSL, с которой они скомпонованы.
- SSH: аналогичный алгоритм
mlkem768x25519-sha256используется в OpenSSH по умолчанию начиная с версии 10.0 (RFC 10042).
Проверка постквантового TLS в браузере показывает, о чём договаривается ваш собственный браузер.
Что когда выбирать
- Публичный HTTPS и API: предлагайте X25519MLKEM768 первым, а X25519 вторым; все современные клиенты согласуют гибрид, а старые перейдут на запасной вариант.
- Внутренняя сервисная сетка (service mesh) и mTLS: гибрид по умолчанию, особенно для данных, которые должны долго оставаться конфиденциальными.
- Развёртывания с ориентацией на FIPS:
SecP256r1MLKEM768илиSecP384r1MLKEM1024, если список одобренных алгоритмов вашего модуля требует кривых NIST; X25519MLKEM768 подходит там, где одобренным компонентом считается ML-KEM. - Каналы с ограниченной пропускной способностью, где на счету каждый пакет: сначала измерьте; гибрид добавляет по одному пакету в каждом направлении, что обычно допустимо.
- Только X25519: лишь для узлов, которые не умеют работать с гибридом, и никогда как осознанный выбор для новых развёртываний.
Заметки о миграции
- Обновите библиотеку TLS (OpenSSL 3.5 или новее, Go 1.24 или новее, актуальные BoringSSL или rustls); в OpenSSL 3.5 группы по умолчанию уже включают гибрид.
- Если вы задаёте группы явно, добавьте его: например,
ssl_ecdh_curve X25519MLKEM768:X25519:prime256v1;в nginx илиGroups = X25519MLKEM768:X25519:P-256в файле конфигурации OpenSSL. - Проверяйте весь путь, а не только сервер: балансировщики нагрузки, WAF и прокси с инспекцией TLS должны справляться с ClientHello, разбитым на несколько пакетов и чтений; повторяйте проверку после их обновлений.
- Проверьте, о чём договариваются стороны, с помощью
openssl s_client -groups X25519MLKEM768или инструментов разработчика в браузере и следите за долей гибридных рукопожатий. - Планируйте переход подписей отдельно: гибрид защищает только конфиденциальность; сертификаты и подписи рукопожатия остаются классическими, пока в WebPKI не появятся постквантовые подписи.
Источники
- RFC 10024, механизмы гибридного согласования ключей PQ/T для TLS 1.3
- RFC 9954, гибридный обмен ключами в TLS 1.3
- FIPS 203, ML-KEM
- RFC 7748, X25519
- Реестр IANA TLS Supported Groups
- Примечания к выпуску OpenSSL 3.5
- tldr.fail: ошибки при фрагментации ClientHello
- NIST IR 8547 ipd, § 4.1.2 (установление ключей)