18:00, June 23 2026
タイトルの通りです。関ヶ原Ruby会議から帰ってきたらやろうと思っていたら 既に手をつけられていた ので現状についてまとめることをしようと思います。ファイル名についていうと、関ヶ原の時点で何人かに「PQC対応入らないとRubyは勝手にオワコンになるよ、なので近く手をつけるよ」みたいな話をしていたことに由来しています。
現代の公開鍵暗号を支える素因数分解の困難性や（楕円曲線上のものを含む）離散対数問題は量子コンピュータの登場によって破られることが知られており、そのような性質に依存しない方式の暗号アルゴリズムが提唱され、アメリカのNISTはFIPS 203(ML-KEM), 204(ML-DSA), 205(SLH-DSA)でこの標準化を行いました。ML-KEMは鍵のカプセル化を行うKey Encapsulation Mechanismで、現在のDiffie-Hellman鍵交換（とそれをベースにするDHKEM）の後継となるもので、ML-DSA・SLH-DSAは電子署名、現在でいうECDSAなどの後継となるものです。
OpenSSL 3.5からEVP_PKEYにML-DSAとML-KEMが加わっており、これに合わせて去年の段階でSSLSocketがPQCのアルゴリズムを使えるように対応が入っています:
なおSLH-DSAはOpenSSL上にあることにはあるのですが、「実装がまだ使える状態ではなさそう」（上記 #894 へのコメント参照）ということでテストケースには追加されていません。
EVP_PKEYのレイヤーでアルゴリズムが生えてるということはEVP_PKEYで動作するKEMのインターフェースがあればML-KEMはタダでついてくるはずです。これは最近になって ruby/openssl #1062: Add EVP_PKEY KEM operations で追加されました。これを使ってnet-sshでML-KEMを使った鍵交換に対応するpull requestが作られています（net-ssh/net-ssh #1005: Add OpenSSL-backed ML-KEM key exchange）。OpenSSHはpost-quantumでない鍵交換をするとwarningを出すようになりましたが、これが入るとRubyからも怒られずに使えるようになります。
またML-DSAもEVP_PKEYのレイヤーで追加されているということはEVP_PKEYのsign/verifyでタダでついてきそうですが、こちらも昨年6/5のcommitでテストが追加されています（該当部分）。
はい、それはその通りで、Open Quantum SafeというプロジェクトがliboqsというライブラリでNIST指定以外のPQCアルゴリズムもサポートしており、これのRubyのバインディングとしてchrisliaw/roqsというものがあります。
Ruby全く死んでなかった。 去年の時点でOpenSSL 3.5にPQ対応入ったなーとは思ってた（これはRubyKaigi 2025のスライドでも言及している）けどその時点で確認しておくべきだった。Ruby側にほとんど手を入れずにアルゴリズム名だけ指定すればある程度動いてくれるEVPすごい。
ちなみに #1062 ではOpenSSL::PKeyの new_raw_public_key / new_raw_private_key が使われており、これは3年前に #646 にて追加した機能なのだけど、#1062 のauthorと #646 の元になったPR #373のauthorは同じ人。
2.5年前に作業をしていたruby/openssl版HPKEですが、ちゃんとpull requestにしてmergeされました1。gem版HPKEとの違いでいうと、OpenSSL版は Base modeのみ対応、gem版は PSK, Auth, AuthPSKも対応、というのがあります。OpenSSL版のスコープを限定したのはHPKEに依存している現行のRFC(MLS, ECH, OHTTP, ODoH)がBase modeのみを利用しているためです。Internet-DraftでいうとCOSE-HPKEがPSK modeを利用するためこれがRFCになった段階でPSK modeへの対応を検討します。一方でAuthモードについては「正直やめようか」みたいな動きもあるので本当に必要になったタイミングでやろうと思います。
gem版でいいやと思っていた理由として「MLS作るにあたってはHPKEだけじゃなくてそのcipher suiteの中身も欲しい」という理由を挙げていましたが、実際MLSで必要なのは(one-shotの)HPKE とHKDF なので、MLSのsuiteからHKDFの種類を確定すればよく、HKDF単体のAPIは既に存在するので、melos でHPKEとKDFのインスタンスを確定している部分を全部OpenSSL-basedに書き換えることはできそう。
ついでにHPKEに関連するところでいうと、#1062 でKEMのAPIが生えたということはML-KEMだけでなくDHKEMもできるはずなので、DHKEMのテストケースを追加するPRを出しました。
番号を見ればわかる通り、「これ終わったらKEMのインターフェース足すか〜〜〜」と思っていたら #1062 が出てきてひっくり返った ↩