liboqs は、ポスト量子の鍵カプセル化メカニズム(OQS_KEM)と署名方式(OQS_SIG)の実装を 1 つの C API にまとめたライブラリで、OpenSSL 3 向け Open Quantum Safe プロバイダーのエンジンでもあります。ここに挙げる事実は、リリース 0.16.0(コミット 5a1a854b0dc9)を CMake のデフォルトオプションでビルドして確認したものです。このオプションでは、共通鍵暗号のプリミティブに OpenSSL が使われます。README には、すべて大文字の英文で次の警告が書かれています。「現時点では、本番環境で、あるいはいかなる機密データの保護のためにも、このライブラリに依存することは推奨しません。」本番環境で使う ML-KEM と ML-DSA について、各ライブラリの主要な API が何を提供しているかは、OpenSSL、BoringSSL、AWS-LC、Bouncy Castle の各ページに記載されています。
デフォルトのビルドでは 41 個の KEM と 221 個の署名パラメーターセットが有効になっており、各ファミリーの 1 つのパラメーターセットで、鍵生成から検証またはデカプセル化までの一連の処理が完了しました。対象は、NIST 標準の ML-KEM、ML-DSA、SLH-DSA(SLH-DSA は通常版と事前ハッシュ版を合わせて 156 種類)、Falcon、KEM の候補である HQC、Classic McEliece、FrodoKEM、BIKE、NTRU、sntrup761、標準化前の Kyber、そして追加署名方式の候補である MAYO、CROSS、UOV、SNOVA、MQOM です。新しいコードでは Kyber768 ではなく ML-KEM-768 と指定してください。デフォルトのビルドでは、XMSS と LMS のパラメーターセットは 1 つも有効になっていません。
ML-DSA の署名はヘッジ付きです。同じ鍵で同じメッセージに 2 回署名すると異なる署名になったため、テストではバイト列を比較するのではなく、署名を検証しなければなりません。FIPS 204 のコンテキスト文字列は OQS_SIG_sign_with_ctx_str で利用できます。コンテキスト invoice-v1 で作成した署名は、invoice-v2 でも、空のコンテキストを使う通常の OQS_SIG_verify でも検証に失敗したため、署名側と検証側でコンテキストを一致させる必要があります。切り詰めた署名、3 バイトのデータ、別のデータに対する有効な署名は、いずれも同じ OQS_ERROR を返しました。
ML-KEM のデカプセル化は、破損した暗号文を報告しません。1 ビットを反転させると、OQS_KEM_decaps は OQS_SUCCESS と異なる共有秘密を返しました。これは FIPS 203 の暗黙的拒否が求める動作です。不一致が表面化するのは、導出した鍵を使ったとき、たとえば AEAD の復号に失敗したときだけです。また、この関数は暗号文の長さを受け取らず、ちょうど length_ciphertext バイト(ML-KEM-768 では 1088 バイト)を読み込みます。ML-KEM ツールとポスト量子署名ツールで両方の方式を試してください。