ML-KEM-768 post-quantum

Kyber · первый пост-квантовый стандарт для обмена ключами

Что это

ML-KEM (Module-Lattice-Based Key-Encapsulation Mechanism) — механизм инкапсуляции ключей на решётчатой криптографии. Опубликован NIST как FIPS 203 в августе 2024 года. Основан на схеме CRYSTALS-Kyber, победителе конкурса NIST PQC (2016-2022).

Число 768 — уровень безопасности:

Зачем нужен

Все классические схемы обмена ключами (RSA, DH, ECDH включая X25519) ломаются алгоритмом Шора на квантовом компьютере. Как только появится достаточно мощный квантовый компьютер — весь перехваченный TLS-трафик прошлых лет можно расшифровать задним числом (атака «harvest now, decrypt later»).

ML-KEM основан на задаче Module Learning With Errors (M-LWE) — решётчатой задаче, для которой пока нет эффективного квантового алгоритма.

Как работает KEM (не как DH)

ML-KEM — это не Diffie-Hellman. Это Key Encapsulation Mechanism:

Сервер                                    Клиент
─────────────────────────────────────────────
(pk, sk) = KeyGen()
                    ────pk────►
                                          (ct, K) = Encaps(pk)
                    ◄────ct────
K = Decaps(sk, ct)                        K

       ── оба получили одинаковый ~32-байтовый ключ ──

Клиент инкапсулирует случайный секрет с помощью публичного ключа сервера, получая шифротекст ct и общий ключ K. Сервер приватным ключом декапсулирует шифротекст и получает тот же K.

Размеры (это боль)

Публичный ключCiphertextОбщий секрет
X2551932 байта32 байта32 байта
ML-KEM-512800 байт768 байт32 байта
ML-KEM-7681184 байта1088 байт32 байта
ML-KEM-10241568 байт1568 байт32 байта
Проблема размера: публичный ключ ML-KEM-768 в 37 раз больше, чем у X25519. В TLS ClientHello с гибридной группой X25519MLKEM768 добавляется ~1.2 КБ — из-за этого ClientHello перестаёт помещаться в один TCP-пакет и разбивается на два. Google измерил ~4% median latency increase на десктопе, а на Android (медленные мобильные сети) — больше, поэтому Chrome долго не включал PQ на мобильных.

Гибридные схемы в TLS 1.3

Никто не использует ML-KEM «в одиночку» — в TLS применяют гибрид:

ГруппаКлассикаPQПорядок shared secret
X25519MLKEM768 (0x11EC)X25519ML-KEM-768ML-KEM сначала (по FIPS)
SecP256r1MLKEM768 (0x11EB)P-256ML-KEM-768ECDH сначала
SecP384r1MLKEM1024P-384ML-KEM-1024ECDH сначала

Итоговый общий секрет = конкатенация обоих shared secrets, затем HKDF. Так что даже если ML-KEM неожиданно окажется сломан, X25519 держит защиту от классических атак; если Шор станет реальностью — держит ML-KEM.

Развёртывание

ДатаСобытие
Август 2023Chrome 116 — экспериментальная поддержка X25519Kyber768Draft00.
Апрель 2024Chrome 124 — включено по умолчанию на десктопе.
Август 2024NIST FIPS 203 — финальная стандартизация ML-KEM. Kyber → ML-KEM.
Сентябрь 2024Google Chrome/Chromium переходит на X25519MLKEM768 (0x11EC).
Октябрь 2024Cloudflare включает X25519MLKEM768 на всей сети.
Ноябрь 2024Firefox 132 — X25519MLKEM768 по умолчанию.
Февраль 2025OpenSSL 3.5 — поддержка ML-KEM в основной ветке.
Март 2025BoringSSL, Rustls, wolfSSL — поддержка ML-KEM.
2026Java 25 (LTS) — X25519MLKEM768 в JSSE по умолчанию.

Проверить самому

Открыть в Chromium-браузере:

chrome://net-export

Или зайти на pq.cloudflareresearch.com — там показывают, какая group использована. Если X25519MLKEM768 — значит соединение защищено от квантовых атак.

Или в nginx поднять переменную $ssl_curve в лог/заголовок:

add_header X-SSL-Group $ssl_curve always;

Почему именно 768

NIST рекомендует ML-KEM-768 как «золотую середину»:

Криптографическая основа

Задача M-LWE (Module Learning With Errors):
Даны матрица A и вектор b = A·s + e (mod q).
Найти s, зная A и b, где e — маленькая ошибка.

Для параметров ML-KEM-768: q = 3329, размерность модуля k=3, полиномы степени 256. Кванторезистентность гарантирована, если M-LWE остаётся сложной задачей.

Смежные PQ-стандарты NIST: