Сегодня Cloudflare Workers добавляет поддержку постквантовых алгоритмов в рамках Web Crypto. Они определены в черновике Modern Algorithms in the Web Cryptography API от рабочей группы сообщества и включают:
- ML-KEM-768 и ML-KEM-1024 для инкапсуляции ключей
- ML-DSA-44, ML-DSA-65 и ML-DSA-87 для подписей
- encapsulateBits(), decapsulateBits(), encapsulateKey() и decapsulateKey()
- getPublicKey()
- SubtleCrypto.supports()
- Импорт и экспорт JWK для этих алгоритмов
Для разработчиков, готовящихся к переходу на постквантовую криптографию, эти опциональные API Web Crypto упрощают эксперименты с ML-KEM и ML-DSA без необходимости подключения сторонних криптографических библиотек. Они не предоставляют готовый путь миграции, а скорее служат строительными блоками, которые можно использовать для проверки вашей интеграции.
Эта поддержка доступна при включении флага совместимости webcrypto_modern_algorithms, пока спецификация находится в стадии разработки.
Предыстория
Web Crypto — это один из тех API, которые замечаешь только тогда, когда в них не хватает нужного примитива. Если вы хотите поэкспериментировать с новыми постквантовыми алгоритмами в среде JavaScript, это непросто. Вы либо не можете построить протокол непосредственно поверх Web Crypto, либо вынуждены использовать собственную реализацию криптографии на JavaScript или WebAssembly.
Ни один из вариантов не является идеальным. Они возлагают бремя выбора и поддержки криптографических реализаций на разработчиков, чьи приложения увеличиваются в размере из-за включения криптографического кода. И эту работу приходится повторять для всех зависимых библиотек. Поскольку экосистеме необходимо перейти на постквантовые алгоритмы раньше, чем ожидалось, мы не можем ждать появления более совершенных постквантовых алгоритмов. Разработчикам нужен доступ к этим примитивам уже сейчас, чтобы они могли тестировать, оценивать и улучшать постквантовые интеграции.
В этой статье мы расскажем, как вы можете реализовать эти примитивы сегодня и начать подготовку своих приложений к постквантовой эре.
Краткая версия
Вот как выглядит ML-KEM в Workers. У одной стороны есть открытый ключ. Другая сторона инкапсулирует общий секрет для этого открытого ключа. Владелец закрытого ключа декапсулирует его и получает тот же секрет.
В этом фрагменте пока нет шифрования. ML-KEM предоставляет обеим сторонам общий ключевой материал. Такие протоколы, как Hybrid Public Key Encryption (HPKE), затем передают этот материал в схему формирования ключей и алгоритм AEAD, например AES-GCM.
ML-DSA ближе к тому, что большинство разработчиков уже видели в Ed25519 или ECDSA: генерация пары ключей, подпись байтов, проверка байтов.
Эти примеры намеренно упрощены. Это не протоколы. Это JavaScript-хуки для криптографических примитивов, которые необходимы протоколам.
Почему это важно
Постквантовая миграция — это не просто переключатель. Это множество протоколов, библиотек, сервисов и сред развертывания, которые учатся использовать другие примитивы.
Часть этой работы уже видна в TLS и SSH. OpenSSH добавил support for mlkem768x25519 в 2024 году. Для HPKE в IETF ведется работа над черновиком для постквантовых и гибридных KEM. IETF опубликовал RFC 9964 для ML-DSA в JOSE, а также принятый черновик для JWE с использованием PQ и PQ/T HPKE. Подписи HTTP-сообщений могут использовать различные алгоритмы подписи, если подписывающий и проверяющий согласны с тем, как создавать и проверять подпись.
Чтобы поддерживать все это в Cloudflare Workers, разработчикам требовалась поддержка базовых криптографических примитивов в Web Crypto.
Без нее разработчик Workers мог бы экспериментировать с постквантовым кодом, но ему пришлось бы подключать отдельную реализацию. Это полезно для переносимости и ранних экспериментов, но это не то, к чему должны прийти все рабочие приложения.
Подпись JWT с помощью ML-DSA
Подписанные JSON Web Tokens (JWT) — это привычный пример защиты с использованием JSON Web Signatures (JWS). С помощью panva/jose библиотеки, которая сопоставляет алгоритмы ML-DSA-* с Web Crypto, код приложения выглядит следующим образом:
JWT — это лишь один пример. Главное в том, что библиотеки могут делегировать операции ML-DSA среде выполнения, вместо того чтобы нести собственную реализацию для каждой среды. Поскольку Workers теперь поддерживает ML-DSA нативно, библиотеки могут делегировать подпись среде выполнения, а не поставлять свою реализацию.
HPKE и OHTTP
ML-KEM — это механизм инкапсуляции ключей. Сам по себе он дает двум сторонам общий ключевой материал. HPKE превращает это в полноценную конструкцию шифрования, добавляя схему формирования ключей и AEAD.
Библиотеки, такие как panva/hpke, уже структурированы вокруг Web Crypto и поддержки среды выполнения. Поскольку среда выполнения Workers предоставляет ML-KEM, реализации HPKE могут использовать нативный примитив там, где он доступен.
Это та форма, к которой мы стремимся и для таких протоколов, как OHTTP (о которых мы уже говорили ранее). OHTTP использует HPKE. Если HPKE может использовать постквантовый KEM через Web Crypto, то этот узел может начать обсуждение миграции на набор шифров, поддерживающий эти примитивы.
Библиотекам могут потребоваться изменения интеграции, специфичные для среды выполнения. Здесь HPKE.CipherSuite выбирает реализации в соответствии с алгоритмами, доступными в среде выполнения.
Получение открытого ключа из закрытого
Некоторым протоколам необходимо публиковать или выводить открытый ключ после загрузки закрытого. Раньше это часто означало хранение обоих ключей или выполнение работы, специфичной для формата.
Новый вспомогательный метод getPublicKey() делает это напрямую:
Для ML-KEM использование отличается, так как открытые ключи инкапсулируют, а закрытые — декапсулируют:
Это небольшой API, призванный удалить код, который часто используется в библиотеках, работающих с криптографией на открытых ключах.
Проверка поддержки
Поскольку API пока не поддерживается во всех средах выполнения, библиотеки должны проверять его наличие, а не предполагать, что он существует везде.
Библиотекам, работающим в Workers, Node.js, Deno, браузерах и других веб-совместимых средах, нужна такая проверка. Это также помогает, когда реализована только часть предложения по современным алгоритмам.
Что поддерживается сегодня
Первоначальная реализация в Workers поддерживает ML-KEM-768 в качестве KEM и ML-DSA-44 в качестве алгоритма подписи. Все они требуют установки флага webcrypto_modern_algorithms.
Для полноты картины мы также поддерживаем ML-KEM-1024, ML-DSA-65 и ML-DSA-87. ML-KEM-512 не поддерживается, так как версия BoringSSL, используемая в Workers, его не предоставляет. Вместо того чтобы добавлять отдельную реализацию только для этого варианта, мы начинаем с алгоритмов, доступных через нативную криптографическую библиотеку.
Самый актуальный список поддерживаемых алгоритмов всегда можно найти в нашей документации для разработчиков.
Как это было реализовано
Workers работают на workerd. Это среда выполнения с открытым исходным кодом, построенная на V8. Реализация добавляет поддержку ML-KEM и ML-DSA в слой Web Crypto среды workerd, опираясь на примитивы BoringSSL.
Это изменение также добавляет тесты веб-платформы для API современных алгоритмов, специфичные для Workers тесты поведения флага совместимости и определения TypeScript в новых типах Workers.
Мы выделили это из более крупного предложения от panva. Изменения, обсуждаемые в этом блоге, которые являются первой частью спецификации современного алгоритма Web Crypto, сосредоточены на ML-KEM, ML-DSA, вспомогательных API и поддержке JWK. Другие алгоритмы из предложения W3C Web Incubator Community Group (WICG), такие как SHA-3, cSHAKE, TurboSHAKE и ChaCha20-Poly1305, не являются частью этого первоначального изменения.
Такой меньший объем упрощает проверку. Это также дает авторам библиотек что-то конкретное для тестирования до того, как будет реализовано все предложение по современным алгоритмам.
Обратите внимание, что открытые ключи и подписи ML-DSA значительно больше, чем RSA или Ed25519. Интеграция этих алгоритмов в среду выполнения повышает производительность и снижает необходимость в связке (bundling). Однако это не меняет того факта, что размер ключей, подписей или зашифрованного текста увеличивается при передаче по сети или при хранении.
Что может быть дальше
Предложение WICG охватывает больше, чем просто ML-KEM и ML-DSA. Мы еще не реализовали следующее из первоначального вклада Филипа Скокана в , что потребует дальнейшего рассмотрения. Сюда входят хеш-функция SHA-3, AEAD ChaCha20-Poly1305 (обсуждение XChaCha20-Poly1305 в wicg/webcrypto-modern-algos#1), cSHAKE, TurboSHAKE и HPKE (обсуждается в wicg/webcrypto-modern-algos#2). Реализация уже была протестирована на соответствие тестовым наборам и для проверки корректности.
Существует также практический вопрос о том, когда это должно стать стандартом по умолчанию, а не опциональной функцией. На данный момент все эти алгоритмы скрыты за флагом совместимости. API основан на черновике, и мы хотим получить отзывы от авторов библиотек, прежде чем считать его стабильным.
Начните экспериментировать сегодня
Это изменение само по себе не делает каждый протокол постквантовым. Оно дает разработчикам Workers и авторам библиотек примитивы, которых им не хватало: ML-KEM для инкапсуляции ключей, ML-DSA для подписей и вспомогательные API, которые делают эти примитивы пригодными для использования через Web Crypto.
Если вы поддерживаете библиотеку, которая в настоящее время включает собственную постквантовую реализацию, сейчас самое время попробовать нативный API и сообщить нам, что именно не подходит. Самый быстрый способ найти шероховатости — это запустить поверх него реальный код протокола. Все подробности находятся в нашем журнале изменений.
Мы хотели бы поблагодарить Филипа Скокана за первоначальный вклад и итерации, Феликса Ханау, Джеймса Снелла, Баса Вестербаана и Питера Ву за проверку кода, а также Дэниела Хьюгенса за соавторство в работе над спецификацией, которой следует эта реализация.
