2026/01/15 7:04
**PyCA／Cryptography における OpenSSL の現状** 本書は、OpenSSL を PyCA Cryptography プロジェクトに組み込む際の現在の状態・利用指針、および今後の方針をまとめたものです。
RSS: https://news.ycombinator.com/rss
要約▶
Japanese Translation:
Summary
12年間にわたり
pyca/cryptographyOpenSSL 3 開発中にテストギャップが浮上しました：CI のフレークが RSA での重要な AVX‑512 バッファオーバーフローを検出し、最初はフレークと見なされて無視されました。正式検証作業は BoringSSL と AWS‑LC が行っているものに比べ遅れています。これらは形式的に検証された実装を維持しています。
対照的に
pyca/cryptography著者らは資金が根本原因ではなく、むしろ OpenSSL 固有の設計選択がその回帰を引き起こしていると主張しています。したがって、新機能（ML‑KEM と ML‑DSA）は OpenSSL を必須にしない 方向で進める予定です（これらは LibreSSL/BoringSSL/AWS‑LC のみで利用可能になります）。彼らは wheel 配布時に OpenSSL フォークへのリンクを評価し、実現可能なら OpenSSL サポートを完全に廃止することも検討します。
この転換は
pyca/cryptography本文
公開日: 2026年1月14日
過去12年間、Paul Kehrer と Alex Gaynor は Python の暗号ライブラリ（別名 pyca/cryptography または cryptography.io）を維持してきました。この間、私たちは OpenSSL をコア暗号アルゴリズムの提供元として利用していました。10 月に開催された OpenSSL Conference で私たちの経験について講演しました。本発表では、OpenSSL の進路に関する問題が増大している点を中心に述べています。
OpenSSL 開発上の失敗は深刻化し、OpenSSL 自体またはその利用方法に対して重大な変更が必要だと考えています。
1. OpenSSL の軌跡
| 時期 | 説明 |
|---|---|
| Heartbleed 前（2014 年以前） | メンテナンス不足で期待に遅れを取っていた。 |
| Heartbleed 後直後 | メンテナンスが再活性化され、コードレビュー、CI テスト、ファジング、成熟したリリースプロセスなど大幅な進歩と改善が見られた。 |
| OpenSSL 3（2021） | 新 API と大規模な内部リファクタリングを導入。前バージョンに比べてパフォーマンス、複雑さ、API の使いやすさで後退し、テスト・検証・メモリ安全性も向上していない。フォーク版がこれらの点で進歩している。 |
OpenSSL の方向性について私たちが抱える懸念は、HAProxy が指摘したものと重複する部分があります。
2. 詳細な問題点
2.1 パフォーマンス
- OpenSSL 3 は OpenSSL 1.1.1 と比べ、パースとキー読み込みで大きく後退している。
- バグレポートでは、楕円曲線公開鍵の読み込みが 1.1.1 から 3.0.7 にかけて 5〜8 倍遅くなったと報告され、パフォーマンスは約 3 倍程度に改善しただけで「後退は予想された」と回答された。
- X.509 証明書のパースを OpenSSL から Rust 実装へ移行すると、OpenSSL 3 を 10 倍高速化できた。
- 公開鍵パースを Rust に置き換えると、X.509 パス検証全体で 60％ の速度向上が得られた。
- これらの性能改善は、コピーや割り当て、ハッシュテーブル、間接呼び出し、ロックを回避する単純だが効果的な最適化によるもの。
2.2 複雑さと API
- OpenSSL 3 は OSSL_PARAM を導入し、通常の引数渡しではなくキー–値ペアの配列でパラメータを受け取るようにした。これにより性能が低下し、コンパイル時検証が困難になり、冗長性が増し、コード可読性が低下する。
- 例として ML‑KEM カプセル化は OpenSSL で 37 行（6 回エラーになる呼び出し）を要するのに対し、BoringSSL では 19 行（3 回）で済む。
- 内部構造がさらに複雑になり、多くのソースファイルでカスタム Perl 前処理器を使用している。さらに「プロバイダー」機能によりアルゴリズムを実行時に置き換えられ、割り当て・ロック・キャッシュ・RCU など複雑なメモリ管理戦略が導入され、バグの原因となった。
- OpenSSL の公開 API をその実装まで辿ることは、間接呼び出しやオプションパス、
等により困難である。#ifdef
2.3 テストと検証
- OpenSSL のテストは依然として不十分であり、OpenSSL 3.0 開発サイクル（16 ヶ月間で 19 回のプレリリース）中にギャップが明らかになった。
- CI はフラッキーで失敗を許容する傾向がある。AVX‑512 CPU 上でのみ検出された RSA のバッファオーバーフローは、CI ランナーが AVX‑512 を搭載しているときにしか捕捉されず、結果としてフラッキーとして却下された。
- 3 年後もテスト失敗やクロスコンパイルビルドでコードマージが行われている。
- 公的検証は最先端を追っていない。BoringSSL と AWS‑LC は公式に検証済み実装を採用している。
2.4 メモリ安全性
- OpenSSL は、性能と埋め込み可能性を兼ね備えたメモリ安全言語が存在しなかった時代に作られた。
- pyca/cryptography は 5 年前に Rust コードを導入し、ほぼ全機能を Rust に移行したが、暗号アルゴリズムはまだ OpenSSL を利用している。
- 長期的にメモリ安全言語へのコミットメントが欠如している。
2.5 貢献の障壁
- 資金は問題ではない。OpenSSL は十分な資金を受け取り、BoringSSL や LibreSSL より多くの常勤エンジニアを抱えている。
- API と内部構造の複雑さに至る設計選択はフォーク版では見られず、不必要であったと示唆される。
3. 今後の方向性
- 新機能で OpenSSL の必須化をやめる – ML‑KEM、ML‑DSA 等、LibreSSL/BoringSSL/AWS‑LC にのみ依存する API を追加。
- バイナリウィールの再検討 – 現在は静的リンクで OpenSSL のコピーを含むが、OpenSSL フォークへのリンクや最終的に OpenSSL サポートの廃止を検討。
- 代替ライブラリの追跡 – Graviola など、OpenSSL 派生以外の暗号ライブラリを積極的に監視。
私たちは、基盤となるライブラリを変更することがユーザー、特に再配布者に与える影響を認識しています。これらは軽率な判断ではなく、私たちの懸念の重大さから必要不可欠な行動です。pyca/cryptography の OpenSSL サポートに依存している場合、最も実用的な対策は OpenSSL プロジェクトへ関与し、上記領域で改善を貢献することです。