暗号の仕組み — 盗み見られても大丈夫にする

概要 — まず全体をつかむ

初級では「鍵で施錠、2種類」と捉えました。中級では、組み合わせ方と、周辺の道具を見ます。

詳細 — 1段階ずつ追う

鍵配送問題とハイブリッド

  • 共通鍵の弱点 — 速いが、鍵をどう安全に相手へ渡すか(鍵配送問題)
  • 公開鍵の弱点 — 鍵配送を解くが、計算が遅い
  • ハイブリッド — 最初だけ公開鍵の仕組みで共通鍵(セッション鍵)を確立し、以降は速い共通鍵で。HTTPS(TLS)の基本
アニメーション『ハイブリッド暗号(鍵の受け渡し)』を開く
あなたサーバ
  • あなた通信を始める側。まず共通鍵(セッション鍵)を用意する
  • サーバ公開鍵と秘密鍵を持つ側。届いた包みを秘密鍵で開ける
「▶ 再生」で通しで見るか、「次へ」で1手ずつ進めてください。
0 / 6

共通鍵の確立には2通りあります(この違いが前方秘匿性に効く)。

  • 鍵交換(DH/ECDHE) — 双方が公開値を交換して、同じ共通鍵をその場で作り出す。使い捨てにでき前方秘匿性を持つ(現代TLSの主流)
  • 鍵転送(RSA) — 送る側が共通鍵を公開鍵で暗号化して渡す。前方秘匿性が無く、TLS1.3で廃止された旧方式

TLSの流れは「①鍵交換で共通鍵を確立 → ②以降はAES-GCMなどの共通鍵で高速通信」の順です。

この部分をもっと深く(上級

中級の「最初だけ公開鍵で共通鍵を渡す」を、もう一段分解します。共通鍵(セッション鍵)を用意する方法には2系統あり、この違いが前方秘匿性を左右します。

  • 鍵転送 — 送る側が共通鍵を作り、相手の公開鍵で暗号化して渡す(旧RSA方式)。長期の秘密鍵が将来漏れると、記録された過去の通信もまとめて復号される
  • 鍵交換(DH/ECDH)※1 — 双方が公開値だけを送り合い、同じ共通鍵をその場で共同生成する。毎回使い捨てにすれば前方秘匿性(PFS)※2 を持つ
アニメーション『ハイブリッド暗号(鍵の受け渡し)』を開く
あなたサーバ
  • あなた通信を始める側。まず共通鍵(セッション鍵)を用意する
  • サーバ公開鍵と秘密鍵を持つ側。届いた包みを秘密鍵で開ける
「▶ 再生」で通しで見るか、「次へ」で1手ずつ進めてください。
0 / 6

DH(ディフィー・ヘルマン)の勘所は「秘密の値は一度も回線に流さない」こと。互いに公開してよい中間値を交換し、それぞれ手元の秘密と混ぜると、盗聴者には作れない同じ鍵に独立してたどり着く。楕円曲線版が ECDH で、短い鍵で同じ強度を得ます。これを毎回新しい使い捨て鍵で行う ECDHE が、現代TLSの標準です。

以降の本文は、速い共通鍵暗号(AESなど)で流します。「鍵の合意は公開鍵の世界、本文は共通鍵の世界」という分業は、IPsecのIKEでも同じ発想です。

登場人物メモ:

  • ※1 鍵交換(DH/ECDH) — 秘密を送らずに、双方で同じ共通鍵を作り出す手続き
  • ※2 前方秘匿性(PFS) — 後で長期鍵が漏れても、過去の通信は解読されにくい性質。使い捨て鍵が鍵
やさしく言うと(初級
  • 暗号化 — 平文(読める文)を、鍵を使って暗号文(読めない文)に変える
  • 復号 — 暗号文を、鍵を使って元に戻す

大事なのは、秘密にするのは「鍵」だけで、アルゴリズム(方式)は公開・検証されたものを使うこと。「秘密の方式だから安全」は間違いです。

暗号を支える道具

  • 共通鍵暗号 — AES-128/256など。ブロック暗号+利用モード(GCM等で認証も)
  • 公開鍵暗号 — RSA-2048/楕円曲線(ECC)。鍵交換はDH/ECDHE
  • ハッシュ — 改ざん検知・指紋(SHA-2など)
  • 電子署名 — 本物・改ざんなしの証明(秘密鍵で署名、公開鍵で検証)
この部分をもっと深く(上級

中級で「道具の一覧」を並べました。ここでは中身を開けます。

共通鍵暗号の中身 ── ブロック暗号とモード

AESは固定長(128ビット)ずつ処理するブロック暗号です。安全性は「ブロックをどう連結するか=利用モード」で大きく変わります。

  • ECB(使ってはいけない) — ブロックごとに独立して暗号化する。同じ平文ブロックが必ず同じ暗号文になるため、画像の輪郭のような模様が透ける
  • CBC — 前の暗号文と混ぜて連鎖させ、初期値(IV)で撹拌する。同じ平文でも毎回違う暗号文になる
  • CTR — カウンタから鍵ストリームを作り平文にXORする。並列処理でき高速。nonce(初期値)の一意性が必須
  • GCM(推奨) — CTRに認証タグを足したもの。暗号化と改ざん検知が一体=AEAD
アニメーション『共通鍵暗号(同じ鍵)』を開く
共通鍵暗号 — 同じ1本の鍵で、施錠も開錠も送り手(施錠する)受け手(開錠する)平文こんにちは施錠暗号文X9#a?+…経路を通って届く暗号文X9#a?+…開錠平文こんにちは同じ鍵をどう安全に渡す?= 鍵配送問題盗聴されている経路では、その鍵を渡せない送り手と受け手が「同じ鍵」を共有速いが、鍵の受け渡しが課題

公開鍵暗号の中身 ── 何が「難しい」ので安全か

公開鍵は「片方向は簡単・逆算は極めて困難」という数学に依ります。

  • RSA — 大きな合成数の素因数分解の困難さ。公開鍵から秘密鍵を求めるには巨大な数を素因数に分けねばならず、現実的な時間で解けない
  • 楕円曲線(ECC) — 楕円曲線上の離散対数の困難さ。同じ強度をより短い鍵で得られる(省電力・高速。RSA-2048 ≒ ECC-224 程度)
アニメーション『公開鍵暗号(南京錠)』を開く
公開鍵暗号 — 南京錠にたとえると受け手(本人)南京錠と秘密鍵の持ち主秘密鍵本人だけが持つ・開錠専用①「開いた南京錠(公開鍵)」を、みんなに配る公開鍵は誰でも受け取ってよい送り手(誰でもよい)事前に鍵を共有していない相手でも② 配られた南京錠で施錠(暗号化)平文こんにちは施錠暗号文X9#a?+…③ 秘密鍵を持つ本人だけが開錠暗号文X9#a?+…秘密鍵で開錠平文こんにちは事前に鍵を共有しなくても安全 = 鍵配送問題を解く公開鍵で施錠、秘密鍵で開錠。公開鍵は配ってよい

詳しくは公開鍵暗号へ。ここで押さえるのは「公開鍵は遅いから、鍵の受け渡しに限って使い、本文は共通鍵で回す」という役割分担です。

やさしく言うと(初級

暗号の鍵の持ち方で、2つに分かれます。

  • 共通鍵暗号 — 施錠も開錠も同じ鍵。速いが、鍵の受け渡しが課題
  • 公開鍵暗号2つの鍵(公開鍵で施錠、秘密鍵で開錠)。鍵の受け渡し問題を解く

実際には、この2つを組み合わせて使います(各記事へ)。

実装の勘所

  • 前方秘匿性 — 使い捨て鍵で、後の鍵漏洩から過去を守る
  • 認証付き暗号(AEAD) — 暗号化と改ざん検知を一体で
  • 乱数の質 — 弱い乱数は鍵を予測可能にする(暗号の土台)
  • 鍵管理 — 生成・保管・ローテーション・失効。ここが最重要
この部分をもっと深く(上級

方式が正しくても、使い方を誤ると土台が崩れます。上級で外せない3点です。

  • 認証付き暗号(AEAD)※1 — 暗号化「だけ」では、中身は読めなくても書き換え(改ざん)を見抜けない。AEAD(GCMなど)は認証タグで完全性・真正性も同時に守る。現代は原則AEAD
  • 鍵導出(KDF)※2 — パスワードのような弱い秘密をそのまま鍵にしない。ソルト(利用者ごとの飾り)で同じパスワードでも別の値にし、ストレッチング(計算を意図的に何万回も反復)で総当たりを重くする。専用のKDF(PBKDF2・argon2など)を使う
  • 乱数の質※3 — 鍵・IV・nonce・ソルトはすべて予測不能でなければならない。予測可能な乱数は暗号全体を無に帰す。暗号用途には専用の乱数生成器(CSPRNG)を使い、時刻や連番で代用しない

登場人物メモ:

  • ※1 AEAD — 暗号化と改ざん検知を1つにした方式。暗号化だけの時代の落とし穴を封じる
  • ※2 KDF(鍵導出関数) — 弱い秘密から、ソルトとストレッチングを効かせて鍵を作る関数
  • ※3 CSPRNG — 暗号に耐える予測不能な乱数を作る生成器。ふつうの乱数(乱数種が読める)とは別物
やさしく言うと(初級
  • 通信の暗号化 — HTTPS(盗聴・改ざんを防ぐ)
  • 保存の暗号化 — 盗まれても読めないように
  • 本人確認・改ざん検知 — 電子署名・ハッシュ

守る性質でいえば、暗号は主に機密性を、署名・ハッシュは完全性・真正性を担います。

⚠️ 危殆化と運用

  • アルゴリズムの陳腐化 — MD5・SHA-1・短い鍵は非推奨へ。更新が前提
  • 実装の穴 — 方式が正しくても、実装バグやサイドチャネルで漏れる
  • 鍵の使い回し/固定 — 使い捨てにできず前方秘匿性を失う
  • 量子計算の脅威 — 耐量子暗号(PQC)の標準化が進み、移行が始まっている
この部分をもっと深く(上級
  • 危殆化は前提 — MD5・SHA-1・RSA-1024・短い鍵は、時代とともに破られてきた。「今安全」は「永遠に安全」ではない
  • 暗号アジリティ — 方式・鍵長を後から差し替えられる設計にしておく。使う暗号をコードに焼き付けず、交換可能な部品として扱うのが要点
  • 量子計算の脅威 — 十分な規模の量子コンピュータは、Shorのアルゴリズムで素因数分解・離散対数を効率的に解き、RSA/ECCを破りうる。対抗が耐量子暗号(PQC)への移行
  • 「今盗んで後で解読」 — 暗号化通信を今のうちに保存し、将来の量子で解く懸念(harvest-now, decrypt-later)。記録済みのECDHEすら量子で解かれうるため、この脅威にはPFSでは足りずPQCが要る
  • 実装の穴 — 方式が正しくても、サイドチャネル(計算時間・消費電力)や乱数の欠陥から秘密は漏れる。検証された標準を、正しく使うが鉄則
やさしく言うと(初級
  • 鍵の管理 — 暗号の強さは、結局鍵をどう守るかで決まる
  • 自作暗号 — 検証されていない方式は穴だらけ
  • 古い方式 — 時代とともに破られる。アルゴリズム・鍵長は更新が必要

関連する知識

理解度チェック

そのまま解けます(成績は保存されません)。無料アカウントを作ると、学習の記録と進捗の山登りが始まります。

1. HTTPSが「速い共通鍵」と「鍵を安全に渡せる公開鍵」を両取りする方法は?

2. 過去の通信を、将来鍵が漏れても解読されにくくする性質は?

3. 現代TLSで主流の、使い捨て鍵で前方秘匿性を持つ鍵交換方式を英字5文字で答えてください。

4. 暗号化と改ざん検知を一体で行う「認証付き暗号」を、英字4文字の略語で答えてください。

5. 共通鍵暗号の主な弱点として本文が挙げるのはどれ?

6. 公開鍵暗号の弱点として本文が挙げるのは?

7. TLS1.3で廃止された、前方秘匿性を持たない共通鍵確立の方式は?

8. TLSの基本的な流れとして正しいのは?