ハクソク

世界を動かす技術を、日本語で。

90年代の認証局のRSA鍵を解読しました

2026年9月8日原文(mcpherrin.ca)

概要

  • RSA暗号 の安全性とその歴史的変遷について解説
  • 512ビットRSA鍵 の脆弱性と実際のファクタリング事例の紹介
  • 古いブラウザや証明書 の実験的な利用方法
  • 現代のRSA鍵長 の推奨と量子コンピュータによるリスク
  • 実際の鍵・証明書データ の例示と活用方法

90年代から見たRSA暗号の安全性と実験

  • RSA暗号 は、 大きな半素数の素因数分解困難性 に依存
  • 「大きい」とは何ビットか、時代によって変化
  • Web PKI では10年以上前に 1024ビットRSA が非推奨に
  • 近年、 862ビット（RSA-260） の素因数分解も実現
  • 現在は 2048ビット以上 が主流、将来は 量子コンピュータ で脅威拡大

小さいRSA鍵の脆弱性とファクタリング実験

  • 512ビットRSA鍵 は現代のPCでも分解可能な脆弱性
  • 90年代初期の Web PKI には標準や最小要件が未整備
  • Netscape 4.51 （1999年）には、 E-Certify の512ビットルートCAが存在
  • S/MIME用 と SSL用 の2つの512ビットCAが同梱
  • RSA-155（512ビット） は同年に分解されており、当時から弱かった
  • Netscape は2002年にこれらのルートを削除
  • Internet Explorer には512ビットSSLルートは存在せず、Netscapeのみが対象

実際のファクタリングと鍵の再構築

  • CADO-NFS を用い、Ryzen 9 5950Xデスクトップで実験
    • SSL用 ：32時間で分解
    • S/MIME用 ：29時間で分解
  • 公開鍵の分解により、 秘密鍵 を再構築可能
  • Netscape 4.51 （有効期限前）なら、これらの秘密鍵で証明書発行が可能
    • 実際にVM上で検証
    • 現代TLSとの互換性は皆無、独自サーバをGoで実装

古い証明書・鍵の活用と公開

  • e-certify.fly.dev で実験サイトを公開（現代ブラウザでは閲覧不可）
  • 鍵・証明書・ツール は GitHub（https://github.com/mcpherrinm/ancientroots） で公開
  • 他にも 512ビットのテスト用CA や VeriSignのコードサイニングCA 等のファクタリング例
    • GPUクラスタ を使えば1時間程度で分解可能な場合も
  • 興味があれば、他の古い鍵の分解や用途検証も推奨

実際の証明書・秘密鍵データ例

  • E-Certify RSA 512 Gold Server for SSL
    • 証明書・秘密鍵ペアを掲載
  • E-Certify RSA 512 Gold Client for S/MIME
    • 証明書・秘密鍵ペアを掲載
  • Test VeriSign Commercial Software Publisher CA
    • 証明書・秘密鍵ペアを掲載

セキュリティ評価と現代的意義

  • SSL Labs によるテストサイトの評価は高評価
  • 古い鍵の脆弱性 を実証し、 現代の鍵長要件 が重要であることを再認識
  • 量子コンピュータ時代には、さらに強固な暗号方式への移行が不可欠

まとめ ：

  • 512ビットRSA鍵 は現代では容易に分解可能なため、 安全ではない
  • 古い証明書や鍵 は実験や教育用途として活用可能
  • RSA鍵長の選定 は時代と共に進化し、 今後は量子耐性暗号 が求められる

Hackerたちの意見

基本的に、消費者向けGPUで512ビットの証明書を解読するのに2日かかるって感じだね。でも当時のトラフィックの多くは一時的な鍵を使ってなかったし、そもそも暗号化すらされてないものがほとんどだった！でも、約10年後には、すべてを暗号化するのが普通になったよね。世界中のどの政府が、匿名の政治的発言を解読できるようになるのを待っているのか、ちょっと気になるな。

└

CPU？

└

リンクされてるCADO-NFSのInriaページにはGPUについての言及がなくて、ダウンロードページにもないから、TFAの因数分解は純粋にCPUで行われたんじゃないかと思う。もしそうなら、まだかなりのスピードアップの余地があるかもしれない！CADO-NFSのページには16スレッドのベンチマーク結果が載っていて、アルゴリズムは少なくともある程度は並列化されることを示唆してる。

└

対称暗号がブルートフォース以外で本当に破られることはないかもしれないね。あなたが言ったように、一時的な鍵の交換が本当に重要な部分なんだ。ありがたいことに、ポスト量子TLSの完全な採用に近づいているみたいだけど、最近までの記録された通信には役立たないよね。怖い考えだ。どうやらCloudflareのリクエストの70%がポスト量子TLSを使ってるらしいよ！

└

世界中の政府が匿名の政治的発言を記録して後で解析するのを待っているかもしれないけど、そんなに多くはないと思う。10年以上前の匿名の政治的発言なんて、あんまり面白くないし。10年後に人を罰しても、あんまり効果的じゃないよね。

4つの自動的な「F」がついたSSLレポート、マジで最高のオチだね。

このLLMの出力が完全に信頼できるかは確認してないけど、かなり信じられそうだね。君が確認するのが重要だよ。だって、信じられそうな出力を生成するのがLLMの得意技だから。そうじゃなきゃ、実際にテストしたものだけが正しいって期待すべきだよ。

└

ある程度同意するけど、俺がやりたかったこと（512ビットRSAキーを見つけること）には必須ではないんだ。俺が一番心配してるのは、生成されたスクリプトがいくつかのエントリーを見逃したり、誤分類したりしてるんじゃないかってこと。特に、各ルートの信頼ビットが正しく設定されてるかどうかが気になる。そういうエラーがある可能性は結構高いと思う。でも、ルートが多すぎてブラウザのインストーラーもたくさんあるから、NetscapeのUIが抽出したデータと一致するかどうかは確認しないよ。

└

あなたは、そのページの出力がLLM生成だと仮定してるけど、実際にはページを生成するプロセスのことを言ってるんじゃない？

└

こういう問題では、あまり関係ないよ。LLMが生成した部分は、最終結果にたどり着くためのハードルに過ぎないから。最終結果が得られた時点で、前のステップがそこに到達するのに十分な有効性があったってわかるしね。

面白い部分がAIに任せられちゃったのはちょっと残念だな。カスタムTLS実装が必要だった理由についてのコメントがあればよかったのに。まあ、仕方ないか。追記：リンク先の（意外と短い）Goファイルの一番上のコメントでこの説明を見つけたよ：ターゲットクライアントはNetscape Communicator 4.51（40ビットのエクスポートビルドと128ビットのUSビルド両方）で、時計は2000年に設定されてる。Goのcrypto/tlsは役に立たない：Go 1.14でSSLv3を廃止し、Netscape 4が送るSSLv2互換のClientHelloを受け入れたこともなく、RC4-MD5や40ビットのエクスポートスイートも持ってなかった。だから、このファイルはstdlibのプリミティブの上に独自の小さなSSLv3サーバーサイド実装を持ってる（RSA PKCS#1 v1.5、RC4、DES、3DES、MD5、SHA-1）。サーバーキーは512ビットRSAだから、エクスポートクライアントが直接プレマスタ秘密を暗号化できるようになってるんだ。

└

（投稿の著者として）いくつかのTLS実装を書いたり作業したりしてきたから、あまり面白くはなかったかな。明日仕事に行かなきゃいけないし、現実のCAの問題を解決しなきゃ :) でも簡単に言うと、Goを使いたかったんだけど、SSLv3やSSLv2のClient Hello、40ビットのRC4-MD5エクスポートグレードの暗号スイートをサポートしてないんだ。証明書がちゃんと発行できたのには驚いたよ。そこでもいくつかうまくいかなかったことがあったし、リポジトリのmkcert.shに私の傷跡が残ってるよ。これらすべてはフォローアップの投稿に値するかもしれない。代わりに古いサーバーを動かそうとしたかもしれないけど、たとえ孤立したFly VMでも、インターネットにデプロイするのは避けたかったな。

Hacker Newsで議論の続きを見る