ML-KEM (Module Lattice–based Key Encapsulation Mechanism) — стандарт постквантового обмена ключами на модульных решётках (семейство Kyber), принят NIST как FIPS 203. ML-KEM обеспечивает стойкий к квантовым атакам механизм для установления секретов сессионного шифрования (KEM → KDF → AEAD), служит заменой/дополнением к классическому ECDH (secp256k1, X25519), уязвимому к алгоритму Шора.
Зачем Web3/финтеху: защищать каналы кошельков, нод и оракулов от сценария harvest-now-decrypt-later (перехватить сегодня — расшифровать завтра). В криптоинфраструктуре ожидается гибридный период: ML-KEM вместе с ECDH.
См. также: ML-DSA (подписи, FIPS 204), SLH-DSA (SPHINCS+) (создать при наполнении), BTQ Technologies, Безопасность.
Коротко о математике (без боли)
- Основа безопасности: задача module-LWE/LWR над кольцом полиномов \( R_q=\mathbb{Z}_q[x]/(x^{256}+1) \) с модулем \( q=3329 \).
- Размер модуля \(k\) (2/3/4) задаёт уровень безопасности (см. ниже).
- NTT/полиномиальная арифметика ускоряют операции.
- XOF/хэши: SHA3/SHAKE (обычно SHAKE-128/256) для расширения сидов, матриц и коммитов.
- CCA2-стойкость достигается через Fujisaki–Okamoto (FO) — преобразование KEM из CPA в CCA за счёт повторной проверки/хэширования.
Важно: это обмен ключами, а не подпись. Для подписи используйте ML-DSA.
Профили и размеры (что попадёт в протокол)
| Профиль FIPS 203 | Близкий Kyber | pk (публичный ключ) | sk (секретный ключ) | Шифртекст (ct) | Где применять |
|---|---|---|---|---|---|
| ML-KEM-512 | Kyber-512 | ~800 B | ~1632 B | ~768 B | Клиентские устройства, P2P-каналы кошельков |
| ML-KEM-768 | Kyber-768 | ~1184 B | ~2400 B | ~1088 B | Общесистемный baseline для нод/сервисов |
| ML-KEM-1024 | Kyber-1024 | ~1568 B | ~3168 B | ~1568 B | Долгоживущие секреты, высокие требования |
Примечания:
- Байтовые размеры зависят от формата/энкодинга, порядок — ориентировочный.
- Ключи/ct крупнее, чем у ECDH, но операции быстрые (NTT, векторизация).
- В кернеле безопасности (CNSA 2.0) часто рекомендуют 768 как основной компромисс, 1024 — для «запасов на будущее».
Интерфейс ML-KEM (идеология)
KeyGen → Encaps → Decaps:
KeyGen() → (pk, sk)
Encaps(pk) → (ct, K) Отправитель шифрует общий секрет K получателю Decaps(sk, ct) → K Получатель извлекает тот же K
Далее из K deriv/KDF получают ключи шифрования:
KEK, AEAD_key = KDF(K || контекст || nonce)
FO-преобразование: часть входов/выходов заново хэшируется и проверяется, чтобы защититься от активных атак (CCA2).
Как это работает (интуитивно)
- KeyGen: генерируется сид → случайная матрица A → два «секретных шума» → вычисляются публичные компоненты.
- Encaps: отправитель выбирает случайность, «проецирует» её через A и pk, добавляет шум, пакует всё в ct и извлекает общий секрет K через хэш.
- Decaps: получатель «вычитает» шум, восстанавливает случайность и получает тот же K. Неверные ct отвергаются (FO).
Все детали скрыты в библиотеке: приложению видны байтовые строки.
Производительность и footprint
- Скорость. Тысячи операций/сек на десктопе, сотни — на мобильных CPU; на серверах отличная батчируемость.
- Память/сеть. Главная плата — размеры pk/ct в протоколах рукопожатия. Для краткоживущих сессий это некритично, для многопрыжковых сетей (P2P) — учитывайте MTU/фрагментацию.
- Аппаратные ускорения. SIMD/AVX2/NEON заметно помогают; для экстремальной нагрузки — PIM/спец-IP (см. BTQ).
Где ML-KEM нужен в блокчейне/крипте
- Кошельки и RPC. Шифрование каналов (QR/DEEplink, Relays, gRPC/WebSockets) с KEM→KDF→AEAD, чтобы перехваченный трафик нельзя было расшифровать в «квантовом» будущем.
- Ноды/валидаторы. P2P-рукопожатия, обмен мемпулом, госип-протоколы.
- Оракулы и мосты. Защита транспортных сообщений/подписей-авторов (вместе с ML-DSA для аутентичности).
- Кастоди/биржи. Каналы внутренних сервисов, бэкапы ключей, шифрование хранилищ.
Гибрид: ECDH + ML-KEM
Переход к PQC делают мягко — через гибрид ECDH (X25519/secp256k1) + ML-KEM:
K_classic = ECDH(priv_A, pub_B)
(ct, K_pqc) = ML-KEM.Encaps(pk_B)
K_session = KDF(K_classic || K_pqc || контекст)
Плюсы:
- Двойная стойкость: нужно сломать обе схемы.
- Back-compat: можно принимать «классический» трафик на старых узлах.
Минусы:
- Рукопожатие длиннее и тяжелее; нужен аккуратный дизайн форматов и fallbacks.
Форматы и UX (практика интеграции)
- Версионирование рукопожатий: version, alg=ECDH|ML-KEM|hybrid, длины ключей/ct.
- KDF/AEAD: HKDF-SHA256/512; AEAD — ChaCha20-Poly1305 или AES-GCM.
- Идентификаторы ключей (KID) и ротация: храните метаданные алгоритма/версии, сроки жизни.
- Фрагментация: для on-chain/мессенджеров учитывайте лимиты размера (делите pk/ct на чанки или отправляйте по «out-of-band»).
- HSM/TEE: поддержка больших ключей и API для encaps/decaps.
Риски и best practices
- Сайд-каналы и константное время. Реализация должна избегать ветвлений по секрету, корректно обрабатывать ошибки (не «подсказывать» злоумышленнику).
- RNG/сид. Случайность — критична; используйте системные DRBG, избегайте повторов сидов.
- Декapsulation-оракулы. Не утекать различиями тайминга/ошибок на неверных ct (FO-защита + униформные ответы).
- Совместимость. Явно объявляйте поддержанные профили (512/768/1024); для кошельков — авто-дауншифт до гибрида.
- Крипто-агильность. Отделяйте алгоритм от бизнес-логики: легко переключать профили/версии.
- Хранение ключей. Большие ключи требуют продуманного бэкапа (шифрованные контейнеры, шэрдинг Шамира).
Сравнение с альтернативами
| Схема | Класс | pk / ct / sk (порядок) | Скорость | Плюсы | Минусы |
|---|---|---|---|---|---|
| ML-KEM (Kyber) | Решётки (module-LWE) | ~KB / ~KB / ~KB | Высокая | Баланс размера/скорости, стандартизован FIPS 203 | pk/ct крупнее ECDH |
| ECDH (X25519/secp256k1) | Эллипт. кривые | Десятки байт | Очень высокая | Компактно, дешево | Уязвим к квантовым атакам |
| FrodoKEM | Решётки (матрицы без NTT) | Десятки KB | Ниже | Консервативная математика | Очень большие ключи/ct |
Мини-гайды по внедрению
Кошелёк ↔ сервер (RPC/WebSocket)
- Договоритесь об alg: hybrid по умолчанию.
- Обменивайтесь pk_classic и pk_pqc (или ссылкой на pk_pqc).
- Делайте Encaps с проверкой профиля (768) и сроков ключей.
- KDF по контексту (версии клиента, сети, цели канала).
Ноды/валидаторы
- Храните pk_pqc в peerstore, используйте кэш decaps.
- Включите ротацию и отзыв ключей (CRL/госып).
- Замеряйте RTT/размер рукопожатия; при деградации — fallback на гибрид/кэш.
Оракулы/мосты
- KEM для транспорта + ML-DSA для подписи полезной нагрузки.
- Логируйте alg, profile, kid для аудита.
FAQ
ML-KEM — это «тот самый» Kyber? Да. ML-KEM — стандартизованная форма семейства Kyber с профилями 512/768/1024.
Чем он лучше ECDH? Устойчив к известным квантовым атакам. Цена — большие ключи/ct и немного более тяжёлое рукопожатие.
Какой профиль выбрать? Часто: 768 как база; 512 для лёгких клиентов; 1024 — для долгоживущих секретов/высокого уровня.
Нужны ли подписи вместе с ML-KEM? Да. KEM даёт секрет шифрования, аутентичность обеспечивают подписи (например, ML-DSA).
Это уже готово для основных сетей? Для транспорта — да (оффчейн-каналы, протоколы связи). Для ончейн форматов нужны EIP/прекомпилы/хардфорки (зависит от сети).