共通鍵暗号 ─ AES と動作モードを覗く

学習目標

本講を終えると、以下を達成できるようになります。

• 共通鍵暗号と公開鍵暗号の使い分け、共通鍵が「速くて重い処理向け」である理由を説明できる
• ブロック暗号とストリーム暗号の違いを述べ、AES がブロック暗号である理由を理解する
• AES の 4つのラウンド操作(SubBytes / ShiftRows / MixColumns / AddRoundKey)の役割をそれぞれ 1 行で言える
• 動作モード(ECB / CBC / CTR / GCM) の違いと、なぜ ECB が現代では使ってはいけないかを図で説明できる
• AEAD(Authenticated Encryption with Associated Data) の意味と、AES-GCM や ChaCha20-Poly1305 が現代の標準である理由を述べられる
• OpenSSL で openssl enc を使って AES-GCM 暗号化・復号を実行できる
• 鍵長(128/192/256 bit)の選択基準と、量子計算が共通鍵暗号に与える影響(Grover アルゴリズム)を理解する

このレッスンの目次

共通鍵暗号の位置づけ ─ なぜ世界中で使われるのか

共通鍵 vs 公開鍵 ─ 役割分担

TLS でブラウザが Web サーバと通信するとき、実は両方の暗号方式が 役割分担 しています。最初の鍵交換だけ公開鍵で、本文の暗号化は共通鍵 ─ これが現代の ハイブリッド暗号 の発想です。

つながる知識: WireGuard・QUIC・TLS 1.3 はすべて「鍵交換は公開鍵(ECDH)、本文は共通鍵(AES-GCM か ChaCha20-Poly1305)」というパターン。共通鍵の進化を理解せずにこれらのプロトコルは語れません。

ブロック暗号 vs ストリーム暗号

2つの方式の動き

図の見方:ブロック暗号は「16B ずつ箱詰めして暗号化」。短い平文には padding を足す。ストリーム暗号は「鍵から作った擬似乱数を平文と XOR するだけ」で、長さは元の平文と同じ。実装が単純で速い。両者は使い分けではなく、AES が広く普及した時代の終わりに ChaCha20 が補完として登場した、という関係。

ChaCha20 が補完として広まった理由

AES は Intel/AMD の AES-NI 命令 によりハードウェアアクセラレーションで非常に速いですが、モバイル・組込み(古い ARM など)や AES-NI のない環境では遅い。ChaCha20 は 純粋にソフトウェアだけで高速 な設計で、Google Chrome は早期から AES-NI なし環境で ChaCha20-Poly1305 を優先するようになりました。今の TLS 1.3 はサーバ・クライアントの能力に応じて両者を使い分けます。

AES の中身 ─ 4 つのラウンド操作

1 ラウンドの動き

図の見方:1 ラウンドは 非線形(SubBytes)→ 拡散(ShiftRows + MixColumns)→ 鍵注入(AddRoundKey) の流れ。これを 10〜14 回繰り返すことで、平文の 1 ビット変化が暗号文の 約半分のビット をランダムに変える ─ シャノンの「拡散と混合」の原理が体現されています。

鍵長と安全性

AES-128 が破られた事例は 2024 年現在 実用的にはない(2^128 通りの全数探索は宇宙の年齢を超える時間がかかる)。AES-256 は「念のため強い方を」という選択肢で、性能差はほとんど無視できる。

動作モード ─ ECB の罠から GCM へ

ECB の罠 ─ なぜ使ってはいけないか

ECB は最も単純なモード:平文を 16 B ずつに分け、それぞれを独立に AES で暗号化するだけ。問題は 「同じ平文ブロックは常に同じ暗号文ブロックになる」こと。画像を ECB で暗号化すると、元画像のパターンが暗号文にそのまま透けて見える ─ これが有名な「ECB ペンギン」現象。

図の見方:ECB は同じ入力 → 同じ出力なので、平文のパターンがそのまま見える。CBC は 「前のブロックの暗号文と XOR してから暗号化」 するので、同じ平文ブロックでも前後関係で結果が変わり、パターンが崩れる。最初のブロックだけは前がないので IV(initialization vector) を使う。

CTR モード ─ 並列処理を可能にする

CBC は前のブロックを待つので 逐次的。大ファイルの暗号化や復号は並列化できません。CTR モードはこれを解決:カウンタ(0, 1, 2, 3, ...)を AES で暗号化して鍵ストリームを生成し、それを平文と XOR。各ブロックは独立に計算できるので並列化可能。

CTR モードの動作:
   nonce | counter:0  →  AES(K)  →  KS_0  →  C_0 = P_0 ⊕ KS_0
   nonce | counter:1  →  AES(K)  →  KS_1  →  C_1 = P_1 ⊕ KS_1
   nonce | counter:2  →  AES(K)  →  KS_2  →  C_2 = P_2 ⊕ KS_2
   ...

並列処理: 全 KS_i を独立に計算可能
復号も同じ操作: P_i = C_i ⊕ KS_i

CTR の 大原則:同じ鍵で同じ nonce を 絶対に再利用してはいけない。再利用すると、2 つの暗号文を XOR するだけで両方の平文が漏れる ─ これは前回 第35回 で見た OTP の two-time pad 攻撃 とまったく同じ原理(C1⊕C2 = P1⊕P2 で鍵が消える)。CTR / GCM が事実上「鍵 + nonce で生成した擬似乱数列で OTP する」構造である以上、OTP の鍵再利用が致命的なのと同じ理由で、nonce の再利用も致命的になります。

4 モードの比較

AEAD ─ 暗号化と改ざん検知をワンパッケージで

AD(Associated Data)とは

AEAD の "AD" は 「暗号化はしないが認証はしたい」追加データ。例えば TLS の場合、ヘッダ部(レコードタイプ・バージョン・長さ)は平文のまま 流す必要があるが、改ざんされたら困る。これを AD として渡すことで、暗号文と一緒に認証タグの計算に含められる。

AEAD 暗号化のイメージ:
   plaintext = "Hello"
   AD        = "from=alice&to=bob"   ← 暗号化しない、でも改ざんされたら検出
   key       = (32 byte の AES-256 鍵)
   nonce     = (96 bit のユニーク値、毎回変える)

   ↓ AES-GCM
   ciphertext = (5 バイトの暗号文)
   tag        = (16 バイトの認証タグ)

復号側:
   AES-GCM_decrypt(ciphertext, tag, key, nonce, AD)
   → plaintext または認証エラー
      ・暗号文 ciphertext が 1 ビットでも書き換わっていたらエラー
      ・AD が変わっていたらエラー
      ・nonce が間違っていたらエラー

つながる知識: TLS 1.3 では 暗号アルゴリズムは AEAD のみ に制限されました。それ以前(TLS 1.2 以下)は CBC + HMAC の「Encrypt-then-MAC」方式も使えましたが、パディングオラクル攻撃 など歴史的に多くの脆弱性を生んでいました。AEAD はこれらを構造的に排除する設計です。

OpenSSL ハンズオン ─ 実際に AES-GCM を回す

1. テキストファイルを AES-256-GCM で暗号化

# テストファイル作成
echo "secret message from alice" > plain.txt

# 鍵と IV(nonce)をランダム生成
KEY=$(openssl rand -hex 32)   # 256 bit 鍵 (64 hex chars)
IV=$(openssl rand -hex 12)    # 96 bit nonce (24 hex chars)
echo "KEY=$KEY"
echo "IV=$IV"

# 暗号化(AES-256-GCM)
openssl enc -aes-256-gcm \
    -K "$KEY" -iv "$IV" \
    -in plain.txt -out cipher.bin

# 暗号文を hex で確認
xxd cipher.bin

2. 復号して元に戻す

# 復号
openssl enc -aes-256-gcm -d \
    -K "$KEY" -iv "$IV" \
    -in cipher.bin -out decrypted.txt

cat decrypted.txt
# → secret message from alice

3. パスワードベース暗号化(より実用的)

# パスワードから鍵を派生(PBKDF2)
openssl enc -aes-256-cbc -salt -pbkdf2 \
    -in plain.txt -out cipher.enc
# パスワード入力プロンプトが出る

# 復号
openssl enc -aes-256-cbc -d -pbkdf2 \
    -in cipher.enc -out decrypted.txt

パスワードから直接 AES 鍵を作るのは 弱い(辞書攻撃に弱い)ため、-pbkdf2 オプションで PBKDF2 という鍵導出関数を通します。これにより総当たり攻撃のコストが意図的に高くなります。

4. Python での AEAD 例

# pip install cryptography
from cryptography.hazmat.primitives.ciphers.aead import AESGCM
import os

key = AESGCM.generate_key(bit_length=256)
nonce = os.urandom(12)
aesgcm = AESGCM(key)

plaintext = b"secret message"
aad = b"to=bob&from=alice"

# 暗号化
ciphertext = aesgcm.encrypt(nonce, plaintext, aad)

# 復号(AAD が違うと InvalidTag 例外が飛ぶ)
recovered = aesgcm.decrypt(nonce, ciphertext, aad)
print(recovered)  # → b"secret message"

鍵長と量子計算への耐性

共通鍵 vs 公開鍵 ─ 量子の脅威の差

つながる知識: 量子計算機が「いつ来るか」は不明ですが、攻撃者が 今のうちに暗号文を保存しておき、将来の量子計算機で復号する(Harvest Now, Decrypt Later)というシナリオが現実視されています。長期機密(国防・医療記録)では今すぐ AES-256 + PQC への移行が始まっています。詳細は次回の公開鍵暗号で。

まとめと用語チェック

用語チェック

確認問題