CloudflareはCloudflare Workers環境に、耐量子計算暗号アルゴリズムであるML-KEMおよびML-DSAのオプション対応をWeb Crypto APIに追加した。この変更により開発者は、JavaScriptやWebAssemblyによる個別実装を組み込む代わりに、ランタイム環境のネイティブインターフェースを使って、鍵交換とデジタル署名の最新の代替手段をテストできる。
現在、この対応は互換性フラグwebcrypto_modern_algorithmsを通じて利用できる。最新アルゴリズムのインターフェースはなお変更可能なドラフトに基づいているためだ。初回バージョンでは、鍵カプセル化用のML-KEM-768と署名用のML-DSA-44をサポートし、ML-KEM-1024、ML-DSA-65、ML-DSA-87も提供する。一方、ML-KEM-512は、Workersで使用されているBoringSSLのバージョンが対応していないためサポートされない。
新しいインターフェースが提供するもの
今回の追加には、encapsulateBits()、decapsulateBits()、encapsulateKey()、decapsulateKey()の各操作に加え、getPublicKey()、SubtleCrypto.supports()、およびこれらのアルゴリズム向けJWK鍵のインポートとエクスポートが含まれる。対応状況を確認するインターフェースにより、ライブラリはすべてのJavaScript環境でアルゴリズムが利用できると仮定せずに済む。これは特に、Workers、Node.js、Deno、ブラウザーでコードを実行する場合に有用だ。
ML-KEMは単独で完全な暗号化を実行するものではない。共有鍵素材を生成し、それをHybrid Public Key Encryption（HPKE）のようなプロトコルが、鍵スケジュールやAES-GCMのような対称暗号アルゴリズムとともに利用する。ML-DSAはEd25519やECDSAに近いモデルを提供し、鍵ペアを生成してデータに署名し、署名を検証する。
なぜこのニュースが重要なのか
耐量子計算暗号への移行は、単一の置き換えによって実現するものではなく、プロトコル、ライブラリ、サービス、デプロイ環境の更新を必要とする。Cloudflareによれば、Web Crypto内にネイティブのプリミティブを提供することで、各ライブラリが個別の暗号実装を同梱する必要性が減り、開発者はML-DSAを使ったJWT署名やHPKE内でのML-KEM利用などの統合を実際にテストできるようになる。これはOHTTPのようなプロトコルにも関係する。
実際には、この変更によってWorkersアプリケーションが自動的に耐量子計算アプリケーションへ変わるわけではなく、どのプロトコルに対しても完全な移行経路が提供されるわけでもない。提供されるのは基礎的な構成要素だけであり、適切なプロトコル、暗号スイート、互換性の仕組みを選ぶ責任は引き続きライブラリ開発者にある。
制限と今後の手順
Workersは、V8を基盤とするworkerd環境内のWeb Crypto層でこれらの機能を実装し、BoringSSLのプリミティブを利用している。今回の追加には、Web Platform Tests、互換性フラグ専用のテスト、新しいTypeScript定義が含まれた。
現段階では、Web Cryptoの最新提案に含まれるその他のアルゴリズム、たとえばSHA-3、cSHAKE、TurboSHAKE、ChaCha20-Poly1305は対象に含まれていない。また、HPKEもWorkers自体のインターフェースの一部にはなっていない。Cloudflareは、ML-DSAの鍵と署名がRSAやEd25519の同等のものよりはるかに大きい点を指摘している。そのため、実装の同梱コストの削減や性能向上によって、ネットワークやストレージ上で鍵、署名、暗号文のサイズが増加する影響がなくなるわけではない。
対応をデフォルトに移行するかどうかは、ドラフトが安定し、ライブラリ開発者からフィードバックを得るまで未決定のままだ。そのため、この追加機能は統合の実験と検証の手段として扱うべきであり、すべてのアプリケーションが直ちに移行できる状態になったことを示すものではない。