OpenSSH のポスト量子暗号化
(openssh.com)- OpenSSH は量子コンピュータの攻撃に備える ポスト量子暗号アルゴリズム をサポートしています
- 9.0 以降、デフォルトで sntrup761x25519-sha512 アルゴリズムを使用し、10.0 からは mlkem768x25519-sha256 をデフォルトの接続方式として適用します
- 10.1 以降は、ポスト量子でないキー交換を使用した場合に 警告メッセージ が表示される変更があります
- ほとんどの既存署名アルゴリズム（RSA、ECDSA など）も将来サポート追加の予定です
- 既存トラフィックを安全に保護するには、サーバーとクライアントの両方で ポスト量子アルゴリズム を適用する必要があります
OpenSSH とポスト量子暗号化の導入
OpenSSH は 量子コンピュータの攻撃でも安全な複数の鍵交換アルゴリズム をサポートしています。
すべての SSH 接続でこれらのアルゴリズムを使うことを推奨しています
OpenSSH 9.0（2022年）から sntrup761x25519-sha512 によりデフォルトでポスト量子鍵交換（KexAlgorithms）を提供し、9.9 からは mlkem768x25519-sha256 が追加されました
mlkem768x25519-sha256 は OpenSSH 10.0 から デフォルトの暗号方式 として指定されています
ポスト量子アルゴリズムの導入を促進するため、OpenSSH 10.1 からは 量子耐性鍵交換 を使用していない場合、次のような警告が表示されます
** WARNING: connection is not using a post-quantum kex exchange algorithm. **
This session may be vulnerable to "store now, decrypt later" attacks.
The server may need to be upgraded. See https://openssh.com/pq.html
この警告はデフォルトで表示されますが、ssh_config(5) の WarnWeakCrypto オプションで 無効化 できます
背景
量子コンピュータ とは、情報を量子状態として符号化して計算するデバイスです。
従来のコンピュータでは不可能な 特定の数学的問題 を高速に解くことができます。
多くの暗号アルゴリズムの数学的基盤は、量子コンピュータで比較的簡単に解ける問題に依存しています。 十分に強力な 量子コンピュータ（暗号学的に意味のある水準）が登場した場合、これらの暗号体系が破られるリスクがあります。 特に 鍵交換 と デジタル署名 に使われるアルゴリズムが最も影響を受けます
こうした量子コンピュータはまだ実現していませんが、専門家は 5〜20年以内、または 2030 年代半ばの出現を予測しています
SSH 接続の プライバシー保護 は鍵交換の暗号化に依存しています。
攻撃者が鍵交換アルゴリズムを突破すると、全セッション内容を復号できます。
加えて、リアルタイムでない場合でも、暗号化セッションを保存 しておき、将来量子コンピュータが出現した時点で復号する '** store now, decrypt later** ' 攻撃が可能です。
OpenSSH はこの攻撃に対応するため、ポスト量子暗号化のサポートを強化しています
FAQ
Q: sshで警告が表示されたという案内を受けたが、どうすればよいですか？
- OpenSSH 10.1 以降では、量子耐性がない暗号化を使用した場合にユーザーへ警告を表示します
- この場合、接続先サーバーが ポスト量子キー交換アルゴリズム（mlkem768x25519-sha256、sntrup761x25519-sha512）を提供していないことを意味します
- 最善策はサーバーを OpenSSH 9.0 以降（後者は 9.9 以降）に アップデート し、KexAlgorithms で関連アルゴリズムが無効化されていないことを確認することです
- もしサーバーのアップデートができない、またはリスクを受け入れる場合は、ssh_config(5) で WarnWeakCrypto オプションを使って警告を隠すことも可能です
- 必要に応じて、次のように特定ホスト向けにのみ対処を適用することを推奨します
Match host unsafe.example.com WarnWeakCrypto no
Q: まだ量子コンピュータがいないのに、なぜ先回りして対策するのですか？
- 先述の "store now, decrypt later" 攻撃が理由です
- 現在送信したトラフィックも、将来復号されるリスクがあるため、事前に ポスト量子安全 な接続が推奨されます
Q: 署名アルゴリズムも危険だと言っていたのに、なぜその時点で問題ではないのですか？
- 現在のほとんどの署名アルゴリズム（RSA、ECDSA など）も量子コンピュータで無効化される可能性があります
- ただしこの場合、既存トラフィックが保存されて後で復号されることはありません
- 署名アルゴリズムの緊急対応は、量子コンピュータの登場が近づいたら既存署名鍵を廃止することです
- OpenSSH は今後、ポスト量子署名アルゴリズム もサポート予定です
Q: 量子コンピュータは実現不可能だと思うが、これはなぜ重要なのか？
- 一部では量子コンピュータは実現不可能だと考えますが、現在の技術的な壁は 基礎物理ではなく工学上の問題 です
- もし量子コンピュータが可能になれば、今日の対策が膨大なユーザーのデータ保護に役立ちます
- たとえ不要な対策だとしても、これは数学的により強力な暗号への 移行 にすぎません
Q: ポスト量子アルゴリズムも脆弱ではないのでしょうか？
- OpenSSH も慎重に進めています
- 過去数年間で集中的に検証されたアルゴリズムだけを採用していますが、新しい攻撃手法 が見つかる可能性は存在します
- これに備え、安全余裕が十分なアルゴリズムのみを採用しており、たとえ想定より弱い場合でも実戦レベルの安全性を維持できる可能性が高いです
- さらに、OpenSSH のポスト量子アルゴリズムはすべて 「ハイブリッド」方式 です
- 例えば mlkem768x25519-sha256 は ML-KEM（ポスト量子）と従来の ECDH/x25519（クラシック）アルゴリズムを組み合わせます
- したがって、将来ポスト量子アルゴリズムが無効化されても、少なくとも従来同等のセキュリティは維持されます
1件のコメント
Hacker Newsコメント
ページ下部に重要な内容が隠れています。OpenSSH に適用されたすべてのポスト量子アルゴリズムは「ハイブリッド」方式で、ポスト量子鍵交換方式（例：ML-KEM）と従来方式（x25519）を同時に使用します。2 つのアルゴリズムを併用することで、将来ポスト量子アルゴリズムが完全に破られたとしても、少なくとも従来と同等のセキュリティを維持できます。ハイブリッドのおかげで、従来に対してセキュリティが低下しない点が重要です
ハイブリッド方式は、一方のアルゴリズムが破られても残りの方で回復力を提供できる利点があります。しかし反対に、実装バグやサイドチャネル脆弱性の露見が2倍以上になることもあります。実際、量子コンピューターの脅威は現実的ではありませんが、そうしたバグや脆弱性は現実の課題です。とはいえ、最近10年間で膨大なセキュリティ研究と検証が進んだことで、このトレードオフも十分に受け入れ可能だと判断します
産業界全体がほとんどハイブリッド PQC-クラシック構造へ移行しています。真に既存の RSA、ECC、DH が破られるレベルの量子コンピューターが現れるまで、2 種類の錠を並行して掛ける保守的な方法が現時点では最も安全な選択だと思います。一方、NSA の CNSA 2.0 アルゴリズム（リンク）はポスト量子系のみを採用し、ハイブリッド方式は不要だと公式 FAQ で明言しています
最近公開された偏向的で面白い論文（リンク）を踏まえると、現在の速度でポスト量子暗号を導入する必要が本当にあるのか疑問です。私の知る限り、ポスト量子キーは従来よりはるかに大きく、ネットワークトラフィックや CPU 消費も大幅に増加します
この論文は SSH 接続で鍵交換にのみ PQC を適用する話なので、オーバーヘッドはかなり小さいレベルです。そして FAQ にもある通り、「量子コンピューターがまだないのになぜ先に準備するのか」という問いに対し、今日送信したトラフィックがあとで復号されるリスク（“store now, decrypt later” 攻撃）によるものです。量子コンピューターの実現が不可能だと主張する人もいますが、主要な障害は物理法則ではなくエンジニアリング上の問題です。もし量子コンピューターが本当に実現すれば、莫大な量のユーザーデータを守ることができます。論文を一度読むのは面白いですが、あまり冷笑的には受け取らないほうがいいです
その論文は笑える部分もありますが、ただ揶揄するだけのものではありません。実際、意味のある進展も進められています。PQCrypto 2025 で Sam Jacques の発表（リンク）をおすすめします。過去10年間で、量子コンピューターを用いた素因数分解コストが1000倍減少し、ハードウェア側の誤り率も大幅に下がりました（リンク1、リンク2、リンク3、リンク4）。量子コンピューターの進展を観察したいなら、漸進的な耐久性向上を追跡すればよいです。ノイズが大きな障壁で、まず両面で品質問題が解決すれば本格的な発展が期待されます
その論文は冗談に思えるほどです。真剣に批判するなら、1951年にトランジスターが円周率を計算できないと不平を言うのと同じです。PQC 導入の必要性は次の2つの質問にかかっています：1）私の人生で量子コンピューターが出現しないと信じるか、2）私が預けたデータの機密性価値をどれだけ重視するか。どちらにもそれほど関心がなければ PQC は時間の無駄かもしれません。ただ、私が暗号システムの維持に関わる立場なら、ユーザーデータの価値を無視する権限はないと思います
現在進行中の議論のほとんどは鍵交換に関するものです。鍵交換はまれにしか行われないため、オーバーヘッドは概ね問題になりません。要点を整理すると：1）PQC アルゴリズム（署名、鍵交換）はキーサイズがかなり大きいですが、計算速度はむしろ速いか同等です。2）TLS、SSH のようなほとんどのプロトコルは初期接続時のみに鍵交換が行われるため、キーサイズが大きいことはそれほど問題になりません。ただし、TCP MTU 超過など互換性の問題は起こり得ます。Signal や MLS のように非常に頻繁に鍵交換するプロトコルでは、時々だけ PQ で再鍵交換します（参考）。3）TLS の場合は署名メッセージサイズの方が問題になります。証明書チェーンに署名が多いからです。したがって PQ 署名の TLS 導入は実行可能性についてより大きな検討が必要です（参考）
公開情報以外にも、我々の情報機関が20年以上機密保持が必要なシステムに PQ 導入を勧めている点は信頼要素です。共有すると、2014 年にはオランダ情報機関が 2030〜2040 年、2021年には 2030年までに現れる可能性は低いが無視できないと述べました。2025年には18か国が共同で論評し、2030年までの「store now, decrypt later」攻撃に備えるよう発表しました（文書1、文書2、共同声明）
Secretive という macOS アプリは Secure Enclave に SSH key を保存します。対応アルゴリズムの関係で ecdsa-sha2-nistp256 を使用しており、Secure Enclave では PQ アルゴリズムはおそらくサポートしていないようです。mlkem768×ecdsa-sha2-nistp256 のようにハイブリッドで束ね、ECDSA 部分だけを SE で処理することが可能か知りたいです（Secretive GitHub）
ssh-audit（リンク）のツールは、理論的アルゴリズム（PQC ハイブリッド）を確認する項目を追加するべきだと思います。特定のアルゴリズムだけ固定して使っても、まだ「A」ランクが表示されるようです。現在は cha-cha だけ使っています
FIPS 140-3 準拠の OpenSSH 用 PQC ハイブリッドアルゴリズムがあるのか気になります
先手を打って備えるアプローチは合理的だと思います。キーの変更が比較的些細な作業のとき、なおさらです。2 つのオプションのうちどちらがより強いか、たぶん 512 のほうがより強いのではないか気になります
2 つのアルゴリズムは完全に異なります。mlkem768x25519-sha256 は、ML-KEM の PQ 鍵交換と従来の ECDH/x25519 を混ぜたハイブリッドです。これにより、どちらか一方が破られても既存レベルのセキュリティを維持できます。さらに 256 バージョン（mlkem768）は、実際には 512 バージョン（sntrup761）より後から登場しました。OpenSSH 9.0 から sntrup761x25519-sha512 サポート、9.9 から mlkem768x25519-sha256 サポートです
256 ビット・512 ビットのサイズの問題について今すぐ心配する必要は全くありません。128 ビット空間を総当たりで探索するための電力さえありませんし、そういったコンピューターもありません。心配する時期はまだです
mlkem は現時点で合理的なデフォルトです。業界標準がこの方向に向かっています
私はターミナルベースのマイクロブログ/チャットアプリを作っていて、この分野（ポスト量子セキュリティ）へ移行するか検討しています。Paul Durov のインタビューを何度も見て、彼の経験を聞くにつれ、ますます悩んでいます
sntrup761x25519-sha512 と mlkem768x25519-sha256 のどちらが良いか気になります
MLKEM768 はより優れたパフォーマンスとより小さいキーを提供します。SNTRUP761 はセキュリティ仮定がより強く、潜在的な暗号解析攻撃に対する耐性が高いです
NTRU Prime（sntrup）は歴史的な理由で入ったものです（mlkem が当時はありませんでした）。どちらを使っても問題ありませんが、sntrup は昔の GPG が CAST をデフォルトで使っていたような、かつてのデフォルトの感覚です
PQ 証明書（ホスト/ユーザー認証用キー）がいつ提供されるか気になります
先にこうした取り組みに踏み出すのは良いことです。将来、より良いセキュリティを備えた代替案が出てきても、現状より悪化しない限り、この努力に意味がないというわけではないと思います