📝 この記事の目次
☕ カフェのWi-Fiはなぜ危険？通信が暗号化されていない恐怖
想像してください。あなたがカフェの無料Wi-Fiに繋ぎ、ショッピングサイトでクレジットカード番号やパスワードを入力して「送信」ボタンを押した瞬間を。
インターネットの通信は、実は「ハガキを郵送する」ようなものです。あなたが入力した文字は、スマホから電波となってカフェの空間を飛び交います。
もし通信に何の保護もかかっていなかった場合、同じWi-Fiに繋いでいる悪意のある人（ハッカー）は、専用のソフトを使うだけでその電波をキャッチし、パスワードを「そのままの文字」で盗み見ることができてしまいます。この「ハガキのように丸見えの通信方式」を、専門用語でHTTP（エイチティーティーピー）と呼びます。
これを防ぐために登場したのが、ハガキを「中身が見えない鍵付きの箱」に入れて送る技術です。これが、URLの先頭につくHTTPS（最後の「S」はSecure＝安全の意味）です。
現在、ほとんどのサイトがHTTPSに対応しており、この「鍵付きの箱を作る技術」のことをTLS（ティーエルエス）と呼びます。
「じゃあ、最初からその『箱の鍵』をかけて送ればいいよね！」と思うかもしれないけど、実は『インターネット越しに、見知らぬ相手へ安全に鍵を渡す』って、とんでもなく難しいことなんだよ🐾
1. 暗号化のジレンマ：速度か、安全な鍵渡しか
通信を暗号化するには「鍵」が必要です。しかし、どのような鍵を使うかで、技術者たちは大きなジレンマを抱えていました。
① 速いが弱点がある「共通鍵暗号（AES）」
暗号化と復号に「同じ1本の鍵」を使う方式です。現代の主力はAESで、非常に処理が速いのが特徴です。AES-256ともなれば、鍵を総当たり（全探索）で探す方法は、現在知られている計算手段では現実的ではありません。
しかし、共通鍵暗号には『鍵配送問題（Key Distribution Problem）』という致命的な弱点があります。ネット上で初めて通信する相手に対して、「通信を暗号化するための最初の鍵を、暗号化されていない通信経路でどうやって安全に渡すのか？」というパラドックスです。
② 鍵渡しを解決するが遅い「公開鍵暗号（RSA）」
そこで登場したのが、数学的に結びついた2本一組のペア（誰にでも見せていい「公開鍵」と、自分だけの「秘密鍵」）を使う公開鍵暗号です。
公開鍵暗号なら、鍵配送問題は解決します。しかし計算が複雑すぎるため、共通鍵（AES）に比べて処理が大幅に遅い（🐢）という欠点がありました。こんなものを動画や画像の暗号化に使えば、インターネットはまともに動きません。
🔬 もっと深く知りたい方へ：各暗号の鍵長と現在の安全性目安
■ 共通鍵暗号の鍵長
| アルゴリズム | 鍵長 | 安全性の目安 |
|---|---|---|
| DES / 3DES | 56〜168 bit | ❌ 使用しない（NIST：DESは2005年に標準廃止、3DESは2023年末で暗号化への使用不可） |
| AES-128 | 128 bit | ✅ 現在安全（一般用途） |
| AES-256 | 256 bit | ✅ 現在安全（長期の保護を重視する用途向け） |
■ 公開鍵暗号（RSA）の鍵長
| RSA鍵長 | 安全性 | 相当する共通鍵 |
|---|---|---|
| 512〜1024 bit | ❌ 新規の保護用途では使わない（512bitは1999年に公開の素因数分解成功例あり。1024bitは新規の暗号保護に認められていない「非推奨」であり、「解読済み」という意味ではありません） | 共通鍵56〜80bit相当 |
| 2048 bit | ⚠️ 2030年以降は非推奨の予定（NISTドラフト） | 共通鍵112bit相当 |
| 3072 bit以上 | ✅ 現代の標準（長期安全性） | 共通鍵128bit以上相当 |
※NIST SP 800-131A Rev.2 では、RSAの鍵長が2048bit未満（1024bitを含む）だと、必要な安全強度（112bit）に届かないため、署名の生成には使えない扱いです（既存の署名の検証のみ、従来どおり認められています）。これは「その鍵長が必要な安全強度に届かない」という基準の話で、個々の1024bit鍵が実際に破られたという報告とは別です。
※米国国立標準技術研究所（NIST）の「SP 800-57 Part 1 Rev.5」では、112bitセキュリティ（RSA-2048）は2030年まで許容され、2031年以降は新たな暗号保護には使えなくなるため、128bitセキュリティ（RSA-3072）以上への移行が求められています。さらに2024年に公表されたNISTのドラフト（SP 800-131A Rev.3、IR 8547）では、2030年以降は「非推奨」、2035年以降は「使用不可」とする案が示されています（いずれもドラフト段階です）。
2. ほんの一瞬で行われる「TLSハンドシェイク」とは？HTTPS通信の仕組み
「AESは速いが鍵を渡せない」「RSAは鍵を渡せるが遅い」。
この2つを組み合わせたハイブリッド方式の考え方が、現在のHTTPSの土台です。
あなたがブラウザでHTTPSのサイトを開いた瞬間、裏側ではわずか数十ミリ秒の間にTLSハンドシェイクと呼ばれる「暗号の取り決め」が行われています。最新のTLS 1.3ではこの通信のやり取りが最適化され、たった1往復（1-RTT：Round Trip Time）で鍵交換を完了できる仕組みになっています。
※上の図は、TLS 1.3の鍵交換方式のうち (EC)DHE を使う場合の簡略版です。TLS 1.3 は鍵の確立方式として (EC)DHE、PSK（事前共有鍵）のみ、PSK＋(EC)DHE の3つを定めています（RFC 8446 第2章）。
「公開鍵の技術で共通鍵を安全に作り出し、共通鍵の技術で高速に通信する」。これが、私たちのネット生活を裏で支えているHTTPSの基本の考え方です。
🔒 過去の通信を守りやすくする「使い捨ての鍵」
TLS 1.2 以前には、サーバーのRSA公開鍵で共通鍵のもとになる値を暗号化して送る「RSA鍵配送」という方式がありました。この方式には、「もし未来のいつか、サーバーのRSA秘密鍵が盗まれてしまった場合、それまでに記録されていた通信まで解読されうる」という弱点があります。TLS 1.3 では、このRSA鍵配送（静的RSA）の暗号スイートは取り除かれました（RFC 8446 第1.2節）。
TLS 1.3 で公開鍵を使って鍵を確立する方式は、通信のたびにその場限りの「使い捨ての鍵」を作る「ディフィー・ヘルマン（DH）鍵交換」（(EC)DHE）を使います。
これのおかげで、サーバーの長期の秘密鍵が後から漏れても、過去の通信がまとめて解読される事態を避けやすくなります。この性質を、専門用語で「前方秘匿性（Forward Secrecy）」と呼びます。初心者のうちは「毎回鍵が新しくなるから、長期の秘密鍵が漏れても過去の通信は解読されにくい」とだけ覚えておけば十分です。ただし、使い捨ての鍵を使い終わったら確実に破棄する実装であることが前提です。また、TLS 1.3 の PSK のみのモードは、前方秘匿性を失う代わりに使える方式と説明されています（RFC 8446 第2.2節）。
🔬 ここから先はマニア向け！DH鍵交換の数学的トリック（読まなくても進めるよ🐾）
DH鍵交換は「掛け算の余り（べき乗剰余）を計算するのは簡単だが、その答えから元の累乗数を逆算することは困難である」という『離散対数問題（DLP）』の非対称性を利用した数学的トリックです。現在主流のECDHEではこれを楕円曲線上で行う『楕円曲線離散対数問題（ECDLP）』を用いることで、RSA-3072と同等の安全性を、はるかに短い鍵長で実現しています。
② アリスは秘密値 a=6 を選び、A = (5^6 mod 23) = 8 を公開
③ ボブは秘密値 b=15 を選び、B = (5^15 mod 23) = 19 を公開
④ アリスは届いたBを使って (19^6 mod 23) = 2 を計算
⑤ ボブは届いたAを使って (8^15 mod 23) = 2 を計算
🎉 通信経路上には「8」と「19」しか流れていないのに、双方が同じ秘密鍵「2」を共有できた！
3. 鍵マーク（HTTPS）の罠：証明書だけで安全と信じてはいけない理由
TLSハンドシェイクによって、通信の途中で盗み見されるリスクは大きく下がりました。カフェのWi-Fiで、パスワードをそのまま盗み見られる心配はずっと小さくなります。
しかし、サイトがHTTPS対応している（アドレスバーに「🔒（鍵マーク）」が出る）からといって「このサイトは安全だ」と信じ込むのは非常に危険です。
※「鍵マーク＝安全」という誤解が広まりやすいという理由もあり、Chromeでは2023年に鍵マークが別のアイコンへ変更されました。鍵マークを表示するブラウザも残っていますが、意味は同じ「通信の暗号化」だけです。
⚠️ フィッシングサイトもHTTPSに対応している
HTTPSの表示（鍵マーク）は「あなたとサーバー間の通信が暗号化されている」ことを示すだけで、「そのサーバーが善人である」ことは証明しません。悪意のあるハッカーが作った偽物のAmazonサイト（フィッシングサイト）でも、無料で証明書を取得してHTTPS対応にすることができるのです。
実は、サーバーが提出する「身分証明書（SSL証明書）」は、『認証局（CA：Certificate Authority）』という第三者機関によって暗号学的な署名付きで発行されています。私たちのブラウザやOSには最初から安全な「ルート認証局」のリストが組み込まれており、そこから枝分かれする『信頼のチェーン（Chain of Trust）』をたどって身元を確認します。この審査レベルには3つの段階が存在します。
DV（ドメイン認証）
ドメインの所有権だけを確認。無料で即時発行できるため、個人ブログからフィッシングサイトまで広く使われる。
OV（組織認証）
運営組織の法的実在を審査して発行される。企業サイトなど向け。
EV（拡張認証）
最も厳しい審査。組織の法的地位・物理的所在・電話確認まで行う。銀行や証券会社など、高い信頼性が求められるサイト向け。
どの種類の証明書（DV・OV・EV）が使われているかは、アドレスバーの🔒マーク（Chromeでは設定アイコン）をクリックして証明書の詳細から確認できます。ただし、証明書の種類は審査の厳しさの違いであり、サイトの善悪を保証するものではありません。
💡 試しに今、確認してみましょう！
今開いているこのページのURL欄にある「🔒マーク（または設定アイコン）」をクリックしてみてください。暗号カフェのドメイン名と、接続が安全であることが表示されるはずです。これが「証明書を確認する」という行動です。
「これで通信中は安全だね！でも…無事に届いた先のサーバーがハッキングされたらどうなるんだ！？💦」
🔍 次の記事へ
これで、あなたが入力したパスワードが「通信の途中」で盗み見されるリスクは大きく下がりました。
しかし、無事にAmazonやX（旧Twitter）のサーバーに届いたパスワードは、その後どうなるのでしょうか？もし、その会社のデータベース自体がハッカーに盗まれてしまったら？
次は、通信の「到着地点」であるサーバー側で、パスワードがどのように安全に保管されているのかを見ていきましょう！