Это перевод статьи Фабиана Каммеля (ControlPlane), опубликованной в официальном блоге Kubernetes. В ней рассказывается о том, как развивается постквантовая криптография, что она значит для TLS и почему Kubernetes оказался впереди в её внедрении.
С появлением квантовых компьютеров мир криптографии оказался на пороге глобальных изменений. И пусть для многих задач мощные квантовые компьютеры пока ещё остаются в планах, их потенциальная способность взломать текущие стандарты шифрования вызывает серьёзное беспокойство, особенно для систем, рассчитанных на долгий срок службы. Именно здесь на сцену выходит постквантовая криптография (Post-Quantum Cryptography, PQC). В этой статье я расскажу, что PQC означает для TLS и, что более важно, для экосистемы Kubernetes. Поговорим о том, как на самом деле (и это вас удивит!) обстоят дела с PQC в Kubernetes и как это потенциально повлияет на кластеры — те, что уже работают, и те, что ещё появятся.
Что такое постквантовая криптография
Постквантовая криптография (PQC) — совокупность криптографических алгоритмов, которые считаются устойчивыми к атакам со стороны как классических, так и квантовых компьютеров. Основная угроза заключается в том, что квантовые компьютеры, использующие, например, алгоритм Шора, способны эффективно взламывать широко распространённые криптосистемы с открытым ключом. К таким системам относятся RSA и криптография на эллиптических кривых (Elliptic Curve Cryptography, ECC), на которых базируется большинство современных защищённых протоколов, включая TLS. В настоящее время сообщество активно ведёт работу по стандартизации и внедрению алгоритмов PQC. Одним из таких алгоритмов, стандартизированных Национальным институтом стандартов и технологий США (NIST), стал механизм инкапсуляции ключей на модульных решётках (Module-Lattice Key Encapsulation Mechanism, ML-KEM), ранее известный как Kyber и теперь утверждённый в качестве стандарта FIPS-203 (PDF).
Сложно сказать, когда квантовые компьютеры научатся взламывать классические алгоритмы. Однако ясно, что с переходом на алгоритмы PQC затягивать не стоит. Получить представление о сроках можно из отчёта NIST (PDF), посвящённого переходу на стандарты постквантовой криптографии. В нём говорится, что системы с классической криптографией должны быть признаны устаревшими (deprecated) после 2030 года, а после 2035 года их использование должно полностью прекратиться.
Обмен ключами и цифровые подписи: разные потребности, разные сроки
В TLS защиты требуют две главные криптографические операции:
Обмен ключами — способ, которым клиент и сервер договариваются об общем секрете для шифрования данных. Главная угроза здесь — атака «сохрани сейчас, расшифруй потом». Если злоумышленник сегодня запишет зашифрованный трафик, то в будущем он сможет его расшифровать с помощью квантового компьютера. Именно поэтому переход на постквантовые KEM (механизмы инкапсуляции ключей) — первостепенная задача.
Цифровые подписи нужны для того, чтобы убедиться, что сервер — именно тот, за кого себя выдаёт (иногда так же проверяют и клиента). Аутентификация сервера происходит прямо во время подключения. Это важно, но не так критично, как с ключами, ведь решение о доверии серверу не получится использовать злонамеренно задним числом. Кроме того, современные алгоритмы постквантовых подписей часто требуют больше вычислительных ресурсов и используют ключи и подписи большего размера, нежели классические.
Ещё одна серьёзная проблема при переходе на постквант — обновление корневых сертификатов. Они действуют очень долго и встроены во множество устройств и операционных систем как якоря доверия.
Учитывая вышесказанное, фокус при внедрении PQC в TLS сейчас направлен именно на гибридные механизмы обмена ключами. Они объединяют классический алгоритм (например, Elliptic Curve Diffie-Hellman Ephemeral, или ECDHE) с постквантовым (например, ML-KEM). Итоговый общий секрет будет в безопасности, пока хотя бы один из этих двух алгоритмов остаётся невзломанным. На данный момент наиболее популярна гибридная схема X25519MLKEM768.
Текущее состояние постквантовых механизмов обмена ключами
Поддержка постквантовых KEM стремительно расширяется по всей экосистеме.
Go: стандартная библиотека Go в пакете
crypto/tlsполучила поддержкуX25519MLKEM768в версии 1.24 (вышла в феврале 2025 года). Она включена по умолчанию, если явно не прописаны предпочтения, то есть когдаConfig.CurvePreferencesне задан (nil).Браузеры и OpenSSL: основные браузеры вроде Chrome (131, ноябрь 2024 года) и Firefox (135, февраль 2025 года), равно как и OpenSSL (3.5.0, апрель 2025 года), также научились работать с гибридной схемой на основе
ML-KEM.Apple внедряет поддержку
X25519MLKEM768в 26-й версии своих операционных систем. Если учесть количество устройств Apple в мире, это серьёзно повлияет на глобальное распространение PQC.
Подробности о том, как PQC внедряется в индустрии в целом, смотрите в посте на Cloudflare.
Постквантовые KEM в Kubernetes: неожиданное появление
Что всё это значит для Kubernetes? Его компоненты, включая сервер API и kubelet, написаны на Go.
Начиная с Kubernetes v1.33 (вышла в апреле 2025 года), проект использует Go 1.24. Беглый взгляд на код Kubernetes показывает, что Config.CurvePreferences не задан явно. Это приводит к поразительному выводу: Kubernetes v1.33 по умолчанию поддерживает гибридный постквантовый X25519MLKEM768 для TLS-соединений просто потому, что использует Go 1.24.
Можете убедиться в этом сами. Поднимите кластер Minikube с Kubernetes v1.33.0 и подключитесь к его серверу API через свежий клиент OpenSSL:
$ minikube start --kubernetes-version=v1.33.0
$ kubectl cluster-info
Kubernetes control plane is running at https://127.0.0.1:<PORT>
$ kubectl config view --minify --raw -o jsonpath=\'{.clusters[0].cluster.certificate-authority-data}\' | base64 -d > ca.crt
$ openssl version
OpenSSL 3.5.0 8 Apr 2025 (Library: OpenSSL 3.5.0 8 Apr 2025)
$ echo -n "Q" | openssl s_client -connect 127.0.0.1:<PORT> -CAfile ca.crt
[...]
Negotiated TLS1.3 group: X25519MLKEM768
[...]
DONEВуаля, согласованная группа — X25519MLKEM768! Это огромный шаг к квантовой защищённости Kubernetes, который случился без громких анонсов или отдельного KEP.
Ловушка с несовпадением версий Go
Интересный нюанс связан с версиями Go 1.23 и 1.24. В Go 1.23 добавили экспериментальную поддержку драфта ML-KEM под названием X25519Kyber768Draft00. Он включался по умолчанию, если Config.CurvePreferences не был задан. Kubernetes v1.32 как раз использовал Go 1.23. Но уже в Go 1.24 поддержку драфта убрали и заменили её стандартизированной версией X25519MLKEM768.
И тут возникает вопрос: что случится, если у клиента и сервера версии Go не совпадут (у одного — 1.23, у другого — 1.24)? У них просто не будет общего PQC KEM для установки соединения, поэтому оно откатится к классическим эллиптическим кривым (например, X25519). Как это может выглядеть в реальной жизни?
Представьте себе ситуацию: имеется кластер Kubernetes v1.32 (он работает на Go 1.23 и поэтому использует X25519Kyber768Draft00). Разработчик обновляет kubectl до v1.33 (собран с Go 1.24 и поддерживает только X25519MLKEM768). Теперь, когда kubectl обратится к серверу API (v1.32), у них пропадёт общий PQC-алгоритм. Уровень защиты соединения будет негласно понижен до классической криптографии, из-за чего потеряется вся постквантовая защита, которая была до этого. Этот случай подчёркивает важность понимания последствий обновления версий Go и того, как устроен стек TLS.
Ограничения: проблема с размером пакета
Использование ML-KEM связано с одним важным нюансом — размером его публичных ключей. В закодированном виде ключ для ML-KEM-768 весит около 1,2 килобайта. Из-за этого самое первое сообщение при установке TLS-соединения (ClientHello) может не влезть в один TCP/IP-пакет, особенно если взять стандартные сетевые лимиты (например, максимальный размер Ethernet-кадра в 1500 байт). Некоторые TLS-библиотеки или сетевые устройства не готовы к такому и могут работать со сбоями, так как ожидают, что ClientHello всегда приходит в одном пакете. Эта проблема уже наблюдалась в некоторых проектах экосистемы Kubernetes и в сетевых компонентах. Она грозит обрывом соединений при попытке использовать постквантовые алгоритмы. Подробности можно узнать на tldr.fail.
Состояние постквантовых подписей
Хотя механизмы инкапсуляции ключей (KEM) внедряются всё активнее, постквантовые цифровые подписи пока отстают в плане широкой интеграции в стандартные инструменты. NIST уже опубликовал стандарты для постквантовых подписей, например ML-DSA (FIPS-204) и SLH-DSA (FIPS-205). Однако их внедрение для повсеместного применения (например, для постквантовых центров сертификации) связано с определёнными трудностями, которые разберем ниже.
Увеличенный размер ключей и подписей: алгоритмы постквантовых подписей часто используют открытые ключи и подписи значительно большего размера по сравнению с классическими алгоритмами вроде Ed25519 или RSA. Например, ключи Dilithium2 в 30 раз больше ключей Ed25519, а сертификаты — в 12 раз.
Производительность: операции подписи и проверки могут работать ощутимо медленнее. Некоторые алгоритмы не уступают по скорости классическим, другие же гораздо «тяжелее» — от 10 до 1000 раз. Чтобы улучшить положение дел, NIST проводит второй этап стандартизации постквантовых подписей.
Поддержка в инструментах: основные библиотеки TLS и ПО для центров сертификации пока не обладают полноценной встроенной поддержкой новых алгоритмов. К примеру, по словам разработчиков Go, у интеграции ML-DSA высокий приоритет, но в стандартной библиотеке она появится не раньше Go 1.26 (и это прогноз от мая 2025 года).
У Cloudflare есть библиотека CIRCL, в которой реализованы некоторые постквантовые подписи (например, вариации Dilithium). Они даже поддерживают свой форк Go (cfgo) с интегрированным CIRCL. С cfgo можно поэкспериментировать и нагенерировать сертификаты, подписанные постквантовыми алгоритмами вроде Ed25519-Dilithium2. Увы, для этого требуется нестандартный набор инструментов Go, и в мейнстрим — в тот же Kubernetes или официальный Go — это вряд ли попадёт в обозримой перспективе.
Заключение
Путь к постквантовому Kubernetes уже в самом разгаре, и мы продвинулись по нему дальше, чем кажется на первый взгляд, во многом благодаря тому, что в Go внедрили ML-KEM. Уже с версии Kubernetes v1.33 пользователи по умолчанию получают гибридный постквантовый обмен ключами в большинстве TLS-соединений.
Но нельзя забывать и о подводных камнях: расхождения в версиях Go могут приводить к откату на менее безопасные алгоритмы. Ещё есть проблема с размером пакетов ClientHello. И если PQC для обмена ключами — это уже почти реальность, то постквантовые цифровые подписи и сертификаты пока ещё далеки от массового внедрения. Нам, как мейнтейнерам и участникам сообщества Kubernetes, очень важно держать руку на пульсе, чтобы обеспечить платформе безопасное будущее.