1月15日、pyca/cryptographyの開発チームが「The State of OpenSSL for pyca/cryptography」と題した記事を公開した。この記事では、Pythonの暗号化ライブラリであるpyca/cryptographyにおけるOpenSSLの現状と、その将来的な依存関係の見直しについて詳しく紹介されている。
以下に、その内容を紹介する。
OpenSSLの現状と課題
Pythonのcryptographyライブラリ（pyca/cryptography）は、過去12年間にわたり暗号アルゴリズムの中核をOpenSSLに依存してきた。しかし、OpenSSLの開発方針に重大な懸念が生じており、開発チームはOpenSSLへの依存度を減らす方針を打ち出している。
OpenSSLのこれまでの軌跡は、以下の3つの段階に分けられる。
- Heartbleed以前（2014年以前）: メンテナンス不足により、期待される水準から大幅に遅れていた時期。
- Heartbleed直後: メンテナンス体制が刷新され、コードレビュー、CI、ファズテストの導入など、大幅な改善が見られた時期。
- OpenSSL 3のリリース（2021年以降）: 内部リファクタリングや新APIの導入が行われたが、パフォーマンスの低下、複雑性の増大、APIの使い勝手の悪化など、多くの退行（リグレッション）が見られる時期。
※Heartbleed（ハートブリード）: 2014年に発見されたOpenSSLにおける、「インターネット史上最悪級」と言われた極めて深刻な脆弱性の通称。技術的には、TLSプロトコルの「Heartbeat（生存確認）」拡張機能の不備を突いたもので、システムのメモリ上に存在する秘密情報を外部から読み取られてしまう
1. パフォーマンスの低下
OpenSSL 1.1.1と比較して、OpenSSL 3はキーのロードやパースにおいて著しいパフォーマンス低下が見られる。一例として、楕円曲線公開鍵のロード速度が3倍から8倍遅くなったケースがある。これに対し、pyca/cryptography側でX.509証明書のパース処理をRustへ移行したところ、OpenSSL 3と比較して10倍の高速化を実現した。
2. 複雑すぎるAPIと内部構造
OpenSSL 3で導入されたOSSL_PARAMなどの新しいAPIは、従来の引数渡しではなくキー・バリュー形式の配列を使用するため、コードの冗長性が増し、コンパイル時の検証が困難になっている。
- 例: ML-KEMのカプセル化処理において、BoringSSLでは19行（3つのエラーチェック）で済むところが、OpenSSLでは37行（6つのエラーチェック）を要する。
- 内部実装においても、Perlプリプロセッサの多用や、プロバイダーAPIによる過度な抽象化が、不要なロックやキャッシュ、複雑なRCU（Read-Copy-Update）を招き、バグの原因となっている。
3. テストと検証の不足
OpenSSLプロジェクトはテストの優先順位が十分ではない。
- OpenSSL 3.0の開発サイクルではコミュニティからの報告に過度に依存しており、リグレッションテストを伴わないバグ修正も散見される。
- CI（継続的インテグレーション）の不安定さ（Flakiness）が放置されており、過去にはAVX-512搭載CPUでのみ発生する致命的なバッファオーバーフローが、CIの不安定さとして見逃された例もある。
- BoringSSLやAWS-LCが採用している「形式手法（Formal verification）」による検証においても、OpenSSLは後れを取っている。
4. メモリ安全性への取り組み
現代のセキュリティ重視のライブラリにとって、メモリ安全な言語（Rustなど）への移行は長期的な責務である。pyca/cryptographyは5年前からRustの導入を進め、パース処理の多くを移行してきたが、OpenSSLにはこの分野での進展が見られない。
今後の方針
OpenSSLの現状を深刻に受け止め、pyca/cryptographyは以下のポリシー変更を決定した。
- 新規機能のOpenSSL必須化の廃止: 今後はOpenSSLでの実装を必須とせず、ML-KEMやML-DSAなどの新しいAPIについては、LibreSSL、BoringSSL、AWS-LCでのみ提供する可能性がある。
- バイナリ（wheels）のリンク先変更の検討: 現在、配布用バイナリにはOpenSSLを静的リンクしているが、これを他のOpenSSLフォーク（BoringSSL等）に変更できないか検討を開始する。
- OpenSSLサポートの終了検討: 他のフォークへの切り替えが成功した場合、将来的にOpenSSL自体のサポートを完全に終了することも視野に入れている。
- 代替ライブラリの追跡: Graviolaなど、OpenSSL由来ではない暗号ライブラリの動向も長期的に注視していく。
開発チームは、これらの変更がユーザーや再配布者に大きな影響を与えることを認識しているが、現状のOpenSSLの状況に鑑み、行動が必要であると結論付けている。
詳細はThe State of OpenSSL for pyca/cryptographyを参照していただきたい。
