暗号系ロードマップ：古典暗号・対称鍵・RSA・Diffie-Hellman・楕円曲線・ハッシュ・署名・TLSのPython実装ハブ

なぜ「暗号系」を 1 本のハブに束ねるのか

GA4 で https://yuhi-sa.github.io/posts/20260225_rsa/1/ の PV が直近 7 日間で 16 → 52（+968%）と継続的に爆発浮上している。検索流入を解析すると、「RSA Python 実装」「公開鍵 仕組み」「ECDSA 署名」「Diffie-Hellman 鍵交換」「SHA-256 Python」など、RSA 単体ではなく暗号体系全体に対する需要が見えてきた。これは本ブログにおける暗号トピックが、信号処理・機械学習・最適化とは独立した 第 8 のクラスタとして育ち始めたサインである。

一方で、暗号は「数学的基盤」「アルゴリズム」「プロトコル」「実装ライブラリ」の 4 軸が複雑に絡む領域であり、単発の記事を読み進めるだけでは「結局どこから手を付ければよいか」が見えにくい。本記事は、これら 4 軸を 古典暗号 → 対称鍵 → 公開鍵 → 鍵交換 → 楕円曲線 → ハッシュ → 署名 → プロトコルの 8 段階に整理した集約ハブとして機能する。

本ブログ内の既存記事を起点として、次の 3 本を中核に据える:

1. https://yuhi-sa.github.io/posts/20260225_rsa/1/ — RSA 公開鍵暗号（鍵生成・暗号化・復号・正当性証明・Miller–Rabin 素数判定）
2. https://yuhi-sa.github.io/posts/20201220_binary/1/ — 繰り返し二乗法（バイナリ法）による高速べき乗剰余計算
3. https://yuhi-sa.github.io/posts/20201223_elgamal/1/ — 楕円曲線 ElGamal 暗号（離散対数問題に基づく公開鍵暗号）

これら 3 本に加え、Diffie–Hellman https://yuhi-sa.github.io/posts/20230907_dh/1/（入門）と https://yuhi-sa.github.io/posts/20260614_diffie_hellman/1/（Safe Prime・MITM 対策・ECDH・X25519・Triple-DH まで踏み込んだ詳解版）、拡張ユークリッド互除法 https://yuhi-sa.github.io/posts/20201015_euclidean/1/、OAuth 2.0 / OIDC https://yuhi-sa.github.io/posts/20260226_oauth2_oidc/1/、ゼロトラスト https://yuhi-sa.github.io/posts/20260226_zero_trust/1/、セキュリティ資格 https://yuhi-sa.github.io/posts/20260223_security_certs/1/ を外周に配置することで、理論 → 実装 → プロトコル → 運用 の縦串が通った 1 枚図になる。

既存の信号処理・機械学習側 7 ハブとは独立したクラスタとして整備するが、繰り返し二乗法は離散 DSP 基礎 https://yuhi-sa.github.io/posts/20260613_discrete_dsp_basics/1/ とモンテカルロ最適化 https://yuhi-sa.github.io/posts/20260522_monte_carlo_optimization/1/ の両方とも数値計算の基礎を共有する。橋渡しは §9 で扱う。

1. 学習レベル別ロードマップ

暗号は「数学的厳密性」と「実装ライブラリの使いこなし」の二刀流が必要な領域である。読者の出発点に応じて 4 レベルの進路を示す。

Level 1 — 完全初心者（暗号に初めて触れる）

目標: 「暗号化と復号は鍵で対称／非対称になる」という大枠を掴み、シーザー暗号・XOR 暗号・SHA-256 のハッシュという基本語彙を獲得する。

1. https://yuhi-sa.github.io/posts/20201220_binary/1/ — まず繰り返し二乗法で大きな数のべき乗剰余に慣れる。RSA・DH・ElGamal すべての計算核
2. https://yuhi-sa.github.io/posts/20201015_euclidean/1/ — ユークリッド互除法と拡張版でモジュラ逆元を計算できるようになる
3. https://yuhi-sa.github.io/posts/20260225_rsa/1/ — RSA 鍵生成・暗号化・復号を Python で動かす（教科書 RSA）
4. https://yuhi-sa.github.io/posts/20260703_aes_symmetric_crypto/1/ — AES / ChaCha20 対称鍵暗号。ハイブリッド暗号における「本体暗号化」の役割と AEAD の使い方
5. https://yuhi-sa.github.io/posts/20260223_security_certs/1/ — 暗号技術が試験範囲に入る情報処理安全確保支援士・CISSP の概要

目安: 2〜4 週間。pow(m, e, n) で RSA 暗号化が 1 行で書けると分かれば Level 1 突破。

Level 2 — 数論基礎を体系化（モジュラ算術・素数判定・離散対数）

目標: フェルマーの小定理・オイラーの定理・拡張ユークリッド・ミラーラビン素数判定・離散対数問題を学習言語として獲得する。

1. https://yuhi-sa.github.io/posts/20260225_rsa/1/ — オイラーのトーシェント関数 \(\varphi(N) = (p-1)(q-1)\) 、Miller–Rabin
2. https://yuhi-sa.github.io/posts/20201015_euclidean/1/ — 拡張ユークリッド互除法 → モジュラ逆元
3. https://yuhi-sa.github.io/posts/20230907_dh/1/ — Diffie–Hellman 鍵交換、離散対数問題（DLP）の困難性
4. https://yuhi-sa.github.io/posts/20260614_diffie_hellman/1/ — Safe Prime / MITM 対策 / ECDH / X25519 / Triple-DH の詳解
5. https://yuhi-sa.github.io/posts/20201223_elgamal/1/ — 楕円曲線上の離散対数問題（ECDLP）

目安: 4〜6 週間。「なぜ素因数分解が困難なら RSA が安全と言えるのか」「なぜ離散対数が困難なら DH が安全と言えるのか」を 1 文で答えられるようになる。

Level 3 — 公開鍵暗号を本格理解（RSA・ElGamal・楕円曲線）

目標: 公開鍵 3 系統（素因数分解 / 離散対数 / 楕円曲線離散対数）の困難性仮定の違いと、それぞれの鍵長と速度のトレードオフを言語化する。

1. https://yuhi-sa.github.io/posts/20260225_rsa/1/ — RSA 鍵長 2048〜4096 ビット、\(e = 65537\) の慣習
2. https://yuhi-sa.github.io/posts/20230907_dh/1/ — DH の鍵長 2048〜3072 ビット、群と生成元の選び方
3. https://yuhi-sa.github.io/posts/20260614_diffie_hellman/1/ — Safe Prime、Curve25519 上の ECDH、X25519、Signal Triple-DH
4. https://yuhi-sa.github.io/posts/20260702_elliptic_curve_cryptography/1/ — 楕円曲線暗号の数学と Python 実装：点加算・ECDLP・ECDH・ECDSA・X25519
5. https://yuhi-sa.github.io/posts/20201223_elgamal/1/ — 楕円曲線 ElGamal、256 ビットで RSA 3072 ビット相当の安全性
6. https://yuhi-sa.github.io/posts/20260226_oauth2_oidc/1/ — JWT 署名に RS256 / ES256 が使われる現場

目安: 6〜8 週間。cryptography.hazmat.primitives.asymmetric の API ツリーが読めるようになる。

Level 4 — プロトコル／実装志向（TLS・JWT・ゼロトラスト）

目標: 暗号アルゴリズムを部品として、TLS 1.3 / JWT / OAuth 2.0 / OIDC / ゼロトラストといった現代プロトコルを組み立てる側に回る。

1. https://yuhi-sa.github.io/posts/20260226_oauth2_oidc/1/ — OAuth 2.0 / OIDC と JWT 署名検証
2. https://yuhi-sa.github.io/posts/20260226_zero_trust/1/ — ゼロトラスト・mTLS・PKI
3. https://yuhi-sa.github.io/posts/20260223_security_certs/1/ — CISSP / 情報処理安全確保支援士の出題範囲

目安: 8〜12 週間並行。cryptography.hazmat を読みこなし、自前で署名検証・鍵交換ハンドシェイクを書けるレベル。

2. 古典暗号 → 対称鍵 → 公開鍵 → 鍵交換 → 楕円曲線 → ハッシュ → 署名 → プロトコル（8 段階）

暗号の歴史と学習順序はだいたい一致する。8 段階で一望できる地図を示す。

段階 1: 古典暗号（シーザー・換字・Vigenère）

換字や転置による暗号。鍵空間が小さいので頻度分析で破られる。学習価値は「暗号化＝鍵による関数適用」という抽象を掴むこと。

段階 2: 対称鍵暗号（AES・ChaCha20）

送信者と受信者が同じ鍵を共有する方式。AES-128 / 256（ブロック暗号）と ChaCha20（ストリーム暗号）が現代の主流。Python では cryptography.hazmat.primitives.ciphers から利用する。鍵共有問題が残るため、公開鍵暗号や鍵交換と組み合わせる。ラウンド構成 (SubBytes / ShiftRows / MixColumns / AddRoundKey)・GF(2^8) の数学・ECB/CBC/CTR/GCM モード・nonce 再利用の危険・ChaCha20-Poly1305 との比較から Python 実装（AESGCM / フルスクラッチ AES-128）までは https://yuhi-sa.github.io/posts/20260703_aes_symmetric_crypto/1/ で詳解している。

段階 3: 公開鍵暗号（RSA・ElGamal）

公開鍵と秘密鍵を別にする方式。RSA は素因数分解の困難性、ElGamal は離散対数の困難性に依拠する。詳細は https://yuhi-sa.github.io/posts/20260225_rsa/1/ と https://yuhi-sa.github.io/posts/20201223_elgamal/1/。鍵生成・暗号化・復号の核に繰り返し二乗法 https://yuhi-sa.github.io/posts/20201220_binary/1/ とモジュラ逆元（拡張ユークリッド） https://yuhi-sa.github.io/posts/20201015_euclidean/1/ がある。

段階 4: 鍵交換（Diffie–Hellman・ECDH）

公開な通信路上で、第三者に盗聴されても共通鍵を導出できるプロトコル。離散対数問題の困難性に依拠する。入門は https://yuhi-sa.github.io/posts/20230907_dh/1/、Safe Prime / MITM 対策 / ECDH / X25519 まで踏み込む実装版は https://yuhi-sa.github.io/posts/20260614_diffie_hellman/1/。TLS 1.3 では ECDHE が必須。

段階 5: 楕円曲線暗号（ECC・ECDSA・ECDH）

整数の乗法群の代わりに楕円曲線上の点の加法群を使うことで、はるかに短い鍵長で同等の安全性を実現する。Weierstrass 形式・点加算・ECDLP・P-256 / secp256k1 / Curve25519 の比較から Python 実装（フルスクラッチ + cryptography.hazmat）までは https://yuhi-sa.github.io/posts/20260702_elliptic_curve_cryptography/1/ で詳解している。楕円曲線 ElGamal は https://yuhi-sa.github.io/posts/20201223_elgamal/1/。署名版が ECDSA、鍵交換版が ECDH。

段階 6: ハッシュ関数（SHA-2・SHA-3・BLAKE2）

任意長の入力を固定長に圧縮する一方向関数。衝突困難性・原像困難性・第二原像困難性の 3 性質を満たすことが要件。hashlib.sha256、hashlib.blake2b が Python 標準。署名やパスワード保存の前段で必須。

段階 7: デジタル署名（RSA-PSS・ECDSA・EdDSA）

秘密鍵で署名し、公開鍵で検証することで、メッセージの完全性と送信者認証を同時に提供する。実用上はメッセージそのものではなくハッシュに対して署名する（hash-then-sign パラダイム）。Python では cryptography.hazmat.primitives.asymmetric.padding.PSS、ec.ECDSA を使う。RSA-PSS・ECDSA・EdDSA の数理と Python 実装は https://yuhi-sa.github.io/posts/20260704_digital_signature/1/ で詳解している。

段階 8: プロトコル（TLS・JWT・OAuth・PKI）

ここまでの部品を組み合わせて安全なセッションを構築する層。TLS 1.3 は ECDHE で鍵交換、AES-GCM で対称暗号、ECDSA / EdDSA で署名、SHA-256 でハッシュという完全装備。ハンドシェイクの鍵導出（HKDF）まで含めた詳解は https://yuhi-sa.github.io/posts/20260715_tls13_handshake/1/、応用プロトコルは https://yuhi-sa.github.io/posts/20260226_oauth2_oidc/1/、https://yuhi-sa.github.io/posts/20260226_zero_trust/1/ に進む。

3. 本ブログ内の構成記事マップ

本ハブが束ねる中核記事と、それぞれの位置付けを 1 枚にまとめる。

中核記事（理論 + 実装）

• https://yuhi-sa.github.io/posts/20201220_binary/1/ — 繰り返し二乗法（バイナリ法）。RSA・DH・ElGamal すべての計算核
• https://yuhi-sa.github.io/posts/20201015_euclidean/1/ — ユークリッド互除法 / 拡張版。モジュラ逆元 → RSA の秘密鍵 \(d\) 生成
• https://yuhi-sa.github.io/posts/20260703_aes_symmetric_crypto/1/ — AES / ChaCha20 対称鍵暗号：ラウンド構成 / GF(2^8) / ECB〜GCM モード / AEAD / nonce
• https://yuhi-sa.github.io/posts/20260225_rsa/1/ — RSA 鍵生成・暗号化・復号、Miller–Rabin 素数判定、\(e = 65537\)
• https://yuhi-sa.github.io/posts/20230907_dh/1/ — Diffie–Hellman 鍵交換、群と生成元、DLP の困難性（入門）
• https://yuhi-sa.github.io/posts/20260614_diffie_hellman/1/ — Diffie–Hellman 詳解：Safe Prime / MITM 対策 / ECDH / X25519 / Triple-DH
• https://yuhi-sa.github.io/posts/20260702_elliptic_curve_cryptography/1/ — 楕円曲線暗号詳解：Weierstrass 形式 / 点加算 / ECDLP / ECDH / ECDSA / X25519
• https://yuhi-sa.github.io/posts/20260704_digital_signature/1/ — デジタル署名詳解：RSA-PSS / ECDSA / EdDSA・hash-then-sign・nonce 再利用攻撃
• https://yuhi-sa.github.io/posts/20201223_elgamal/1/ — 楕円曲線 ElGamal、ECDLP、点の加法
• https://yuhi-sa.github.io/posts/20260223_security_certs/1/ — 暗号技術が問われるセキュリティ資格の比較

接続先（プロトコル・運用）

• https://yuhi-sa.github.io/posts/20260226_oauth2_oidc/1/ — OAuth 2.0 / OpenID Connect、JWT 署名（RS256 / ES256）
• https://yuhi-sa.github.io/posts/20260226_zero_trust/1/ — ゼロトラスト・mTLS・PKI

将来追加予定の暗号系記事（プレースホルダ）

本ハブは生きた地図として運用する想定で、以下のテーマは今後の優先候補として明示しておく:

• SHA-2 と HMAC（ハッシュと MAC） → 公開済み: https://yuhi-sa.github.io/posts/20260715_sha256_hmac/1/（SHA-3 / BLAKE2 は今後の課題）
• RSA-PSS / ECDSA / EdDSA（署名スキーム） → 公開済み: https://yuhi-sa.github.io/posts/20260704_digital_signature/1/
• TLS 1.3 ハンドシェイク詳解 → 公開済み: https://yuhi-sa.github.io/posts/20260715_tls13_handshake/1/
• Post-Quantum Cryptography（CRYSTALS-Kyber / Dilithium） → 公開済み: https://yuhi-sa.github.io/posts/20260715_post_quantum_lwe/1/

これらが追加され次第、本ハブにリンクを差し込む形で更新する。

4. 数学的基盤の橋渡し

暗号で繰り返し登場する数学的基盤を 4 つに分けて整理する。

4.1 モジュラ算術（modular arithmetic）

整数を法 \(n\) で割った余りの世界。\(\mathbb{Z}/n\mathbb{Z}\) 。RSA の \(c = m^e \bmod N\) も、DH の \(g^a \bmod p\) も、すべてここで動く。繰り返し二乗法 https://yuhi-sa.github.io/posts/20201220_binary/1/ は \(O(\log e)\) で \(m^e \bmod N\) を計算する手法であり、暗号系の計算量を実用範囲に押し込めている。

4.2 素数判定と素数生成

RSA は大きな素数を 2 つ必要とする。決定的判定 (AKS) は遅すぎるので、Miller–Rabin の確率的判定で代用する。\(k = 20\) 回繰り返せば誤判定率は \(4^{-20} \approx 10^{-12}\) 。詳細は https://yuhi-sa.github.io/posts/20260225_rsa/1/。Python では sympy.isprime が標準。

4.3 離散対数問題（DLP）と楕円曲線離散対数問題（ECDLP）

\(g, h \in (\mathbb{Z}/p\mathbb{Z})^*\) について \(h = g^x \bmod p\) を満たす \(x\) を求める問題が DLP。古典的には準指数時間（一般数体ふるい）でしか解けず、これが DH と ElGamal の安全性の根拠。楕円曲線上では一般攻撃が完全指数時間となるため、より短い鍵で同等の安全性を達成できる。

4.4 オイラーの定理と CRT

\(\gcd(a, N) = 1\) のとき

が成り立つ（オイラーの定理）。RSA の復号正当性 \(c^d = m^{ed} \equiv m \pmod N\) はここから出る。実装では中国剰余定理 (CRT) を使って \(\bmod p\) と \(\bmod q\) で別々に計算し、約 4 倍高速化する手法が広く用いられる。詳しい導出は https://yuhi-sa.github.io/posts/20260225_rsa/1/。

4.5 共通基盤：べき乗剰余の再利用

繰り返し二乗法は暗号だけでなく、素数判定（Miller–Rabin）、離散 DSP の DFT 高速化（https://yuhi-sa.github.io/posts/20260613_discrete_dsp_basics/1/ の FFT は \(O(N \log N)\) の二分木構造を共有）、モンテカルロ最適化（https://yuhi-sa.github.io/posts/20260522_monte_carlo_optimization/1/ のサンプリングで \(O(\log N)\) 累積分布の二分探索）でも本質的に同じ「指数を 2 進展開して分割計算する」アイディアが使われる。

5. Python 実装ガイド — ライブラリの使い分け

暗号は車輪の再発明をしない領域である。自前実装は学習用、運用には認証済みライブラリが鉄則。Python の暗号関連ライブラリを使い分け表で整理する。

5.1 ライブラリ比較表

5.2 使い分けの実務的指針

• 学習・プロトタイプ: sympy.isprime、pow(m, e, n)、自前の extended_gcd で RSA を 1 から書く。https://yuhi-sa.github.io/posts/20260225_rsa/1/ の実装がそのまま使える
• 大きな数の高速演算: gmpy2.powmod、gmpy2.invert、gmpy2.is_prime に切り替える。RSA-4096 の鍵生成が数倍速くなる
• 本番: cryptography.hazmat.primitives.asymmetric.rsa、ec、ed25519、hashes、ciphers のみを使う。自前の RSA を本番投入してはならない
• トークン: pyjwt で JWT、fernet で簡易対称暗号。失敗パターンが少ない
• 乱数: 鍵・nonce 生成は必ず secrets または os.urandom。random モジュールは暗号目的では絶対に使わない

5.3 RSA を 4 ライブラリで書き比べ

# 1) 標準ライブラリのみ（教育用）
import secrets, math
def egcd(a, b):
    if a == 0: return b, 0, 1
    g, x1, y1 = egcd(b % a, a)
    return g, y1 - (b // a) * x1, x1
# pow(m, e, n) で暗号化、pow(c, d, n) で復号

# 2) sympy（プロトタイプ）
from sympy import isprime, nextprime, mod_inverse
p = nextprime(secrets.randbits(1024))
q = nextprime(secrets.randbits(1024))
n, phi = p * q, (p - 1) * (q - 1)
e = 65537
d = mod_inverse(e, phi)

# 3) gmpy2（高速）
import gmpy2
c = gmpy2.powmod(m, e, n)
m_dec = gmpy2.powmod(c, d, n)

# 4) cryptography.hazmat（本番）
from cryptography.hazmat.primitives.asymmetric import rsa, padding
from cryptography.hazmat.primitives import hashes
key = rsa.generate_private_key(public_exponent=65537, key_size=2048)
ct = key.public_key().encrypt(
    b"hello",
    padding.OAEP(mgf=padding.MGF1(hashes.SHA256()), algorithm=hashes.SHA256(), label=None),
)

理論コードと実装 API の橋渡しは https://yuhi-sa.github.io/posts/20260225_rsa/1/ と https://yuhi-sa.github.io/posts/20201220_binary/1/ を併読すると、なぜ pow(m, e, n) が 1 行で済むのかが腹落ちする。

5.4 ハッシュと署名の最短コード

import hashlib, hmac
digest = hashlib.sha256(b"message").hexdigest()
mac = hmac.new(key=b"k", msg=b"m", digestmod=hashlib.sha256).hexdigest()

from cryptography.hazmat.primitives.asymmetric import ec
from cryptography.hazmat.primitives import hashes
sk = ec.generate_private_key(ec.SECP256R1())
sig = sk.sign(b"msg", ec.ECDSA(hashes.SHA256()))
sk.public_key().verify(sig, b"msg", ec.ECDSA(hashes.SHA256()))

6. 鍵長と安全性の比較表

読み方: 同じ行は「同等の安全性を提供する」鍵長。RSA-3072 ≒ ECC-256 ≒ AES-128 ≒ SHA-256 が現在 (2026 年時点) の主流。ECC の鍵長圧縮効果が一目で分かる。

詳細な議論は https://yuhi-sa.github.io/posts/20260225_rsa/1/（RSA-2048 vs 4096）と https://yuhi-sa.github.io/posts/20201223_elgamal/1/（ECC の優位性）を参照。

7. 学習チェックリスト 12 項目

暗号系の理解度を自己診断する 12 項目。

モジュラ算術とアルゴリズム

1. \(m^e \bmod n\) を繰り返し二乗法で \(O(\log e)\) で計算する手順を説明できる（https://yuhi-sa.github.io/posts/20201220_binary/1/）
2. 拡張ユークリッド互除法から \(e \cdot d \equiv 1 \pmod{\varphi(N)}\) の \(d\) を導出できる（https://yuhi-sa.github.io/posts/20201015_euclidean/1/）
3. Miller–Rabin 素数判定の確率的性質を 1 文で説明できる（https://yuhi-sa.github.io/posts/20260225_rsa/1/）

公開鍵暗号と鍵交換

4. RSA の安全性が素因数分解の困難性に依拠することを説明できる
5. Diffie–Hellman の安全性が離散対数問題に依拠することを説明できる（https://yuhi-sa.github.io/posts/20230907_dh/1/）
6. ElGamal と RSA の数学的基盤の違い（DLP vs 素因数分解）を言える（https://yuhi-sa.github.io/posts/20201223_elgamal/1/）

楕円曲線とハッシュ・署名

7. ECC が RSA より短い鍵長で済む理由（ECDLP の困難性）を 1 文で言える
8. ハッシュ関数の 3 性質（衝突困難性・原像困難性・第二原像困難性）を列挙できる
9. hash-then-sign パラダイム（メッセージではなくハッシュに署名）の理由を説明できる

プロトコルと運用

10. TLS 1.3 ハンドシェイクで使われる暗号要素（ECDHE / AES-GCM / ECDSA / SHA-256）を 1 行で説明できる
11. JWT の alg ヘッダで RS256 / ES256 / HS256 の使い分けが言える（https://yuhi-sa.github.io/posts/20260226_oauth2_oidc/1/）
12. 「自前で AES や RSA を実装してはならない」理由（サイドチャネル攻撃・パディング攻撃）を説明できる（https://yuhi-sa.github.io/posts/20260226_zero_trust/1/）

8. よくある詰まりポイント Q&A

Q1. なぜ RSA は遅いのか?

RSA は鍵長 2048〜4096 ビットの多倍長整数でべき乗剰余を計算するため、対称鍵 (AES) の数百〜数千倍遅い。実用では、RSA で AES 用の対称鍵だけを暗号化し、本文は AES で暗号化するハイブリッド方式を取る。TLS もこの構造。ハイブリッド構成の対称鍵側 (AES-GCM / ChaCha20-Poly1305) の詳細は https://yuhi-sa.github.io/posts/20260703_aes_symmetric_crypto/1/。pow(m, e, n) の中身は繰り返し二乗法 https://yuhi-sa.github.io/posts/20201220_binary/1/。

Q2. 離散対数の困難性とは具体的に何か?

「\(g, h, p\) が与えられたとき \(h \equiv g^x \pmod p\) を満たす \(x\) を求める」問題が DLP。\(g^x\) の計算は繰り返し二乗法で \(O(\log x)\) と高速だが、逆問題は一般数体ふるいでも準指数時間 \(\exp(O((\log p)^{1/3} (\log \log p)^{2/3}))\) かかる。これが DH の安全性の根拠。詳細は https://yuhi-sa.github.io/posts/20230907_dh/1/ と https://yuhi-sa.github.io/posts/20260614_diffie_hellman/1/。

Q3. 楕円曲線が省鍵長で済む理由は?

整数の乗法群 \((\mathbb{Z}/p\mathbb{Z})^*\) では準指数時間アルゴリズム（一般数体ふるい）が存在するが、汎用的な楕円曲線上ではそうしたアルゴリズムがまだ発見されていない。Pollard rho 等の汎用攻撃は完全指数時間 \(O(\sqrt{n})\) なので、\(n\) を小さくしても安全性を保てる。\(n = 256\) ビットの楕円曲線が RSA-3072 と同等。詳細は https://yuhi-sa.github.io/posts/20201223_elgamal/1/。

Q4. 教科書 RSA をそのまま使うとなぜ危険なのか?

パディングなしの \(c = m^e \bmod n\) は決定的（同じ平文 → 同じ暗号文）であり、選択平文攻撃 / 選択暗号文攻撃 に脆弱。具体的には Bleichenbacher 攻撃などがある。実用では OAEP（暗号化）と PSS（署名）のランダムパディングを必ず併用する。実装は cryptography.hazmat.primitives.asymmetric.padding.OAEP。詳細は https://yuhi-sa.github.io/posts/20260225_rsa/1/ の「セキュリティ注意」。

Q5. なぜ random ではなく secrets / os.urandom を使うのか?

random はメルセンヌ・ツイスタによる疑似乱数生成器で、過去出力からシード状態が復元可能。鍵や nonce に使うと致命的。secrets モジュールは OS のエントロピー源 (/dev/urandom) を直接使うため、暗号学的に安全。鍵生成・トークン発行は secrets.token_bytes(32) が定石。

Q6. ハッシュと暗号化の違いは?

ハッシュは一方向関数（逆算不可能）。暗号化は鍵で可逆（秘密鍵があれば復号できる）。ハッシュは「同じか」の判定や署名前段に使い、暗号化は「読まれないように」したいときに使う。ハッシュにパスワードを保存する場合は SHA-256 ではなく bcrypt / scrypt / Argon2 を使う（計算コストを上げて総当たり攻撃を防ぐ）。

Q7. ポスト量子暗号 (PQC) はいつ移行すればよいか?

NIST が 2024 年に標準化した CRYSTALS-Kyber（鍵交換）と Dilithium（署名）が現在の主流。Shor のアルゴリズムが実用化される前にハーベスト・ナウ・デクリプト・レイター（今盗み貯めて将来復号する）攻撃を考えると、長期秘匿が必要な通信は早期に PQC へ移行すべき。具体的な移行戦略は https://yuhi-sa.github.io/posts/20260226_zero_trust/1/ の文脈で扱う予定。

9. 関連ハブへの橋渡し

本ハブは暗号系の独立クラスタとして機能するが、繰り返し二乗法と乱数 / モンテカルロ的な確率手法を介して、信号処理・最適化・機械学習のハブと数学的な橋を持つ。

A. 離散 DSP 基礎ハブ — 繰り返し二乗法の数値計算共通基盤

https://yuhi-sa.github.io/posts/20260613_discrete_dsp_basics/1/ の FFT は \(O(N \log N)\) の分割統治構造を持ち、これは繰り返し二乗法 https://yuhi-sa.github.io/posts/20201220_binary/1/ の「指数を 2 進展開して分割計算」の発想と数学的に同根。「二分木構造で計算量を \(O(N)\) から \(O(\log N)\) に落とす」 という共通アイディアが両者を貫いている。

B. モンテカルロ最適化ハブ — 乱数の暗号学的安全性との対比

https://yuhi-sa.github.io/posts/20260522_monte_carlo_optimization/1/ のサンプリングは統計的乱数（np.random）で十分だが、暗号鍵生成では secrets / os.urandom が必須。乱数の「品質」の意味が文脈で異なることを意識すると、両領域の API 設計が立体的に見える。MCMC（https://yuhi-sa.github.io/posts/20260226_mcmc/1/）の擬似乱数列と、暗号 PRNG の違いは Q&A Q5 で触れた通り。

C. DSP/ML メタロードマップ — 全体俯瞰の入口

https://yuhi-sa.github.io/posts/20260528_dsp_ml_roadmap/1/ は信号処理・機械学習の 7 ハブを束ねるメタロードマップ。暗号は別系統だが、「学習ロードマップは段階を設計する」 というメタ原則は共有している。本ハブもメタロードマップで参照されるべき 8 番目のハブとして機能する。

D. その他のハブとの距離感

E. 関連記事まとめ

本ハブが束ねる中核記事

• https://yuhi-sa.github.io/posts/20201220_binary/1/ — 繰り返し二乗法
• https://yuhi-sa.github.io/posts/20201015_euclidean/1/ — ユークリッド互除法 / 拡張版
• https://yuhi-sa.github.io/posts/20260703_aes_symmetric_crypto/1/ — AES / ChaCha20 対称鍵暗号
• https://yuhi-sa.github.io/posts/20260225_rsa/1/ — RSA 公開鍵暗号
• https://yuhi-sa.github.io/posts/20230907_dh/1/ — Diffie–Hellman 鍵交換（入門）
• https://yuhi-sa.github.io/posts/20260614_diffie_hellman/1/ — Diffie–Hellman 詳解
• https://yuhi-sa.github.io/posts/20201223_elgamal/1/ — 楕円曲線 ElGamal
• https://yuhi-sa.github.io/posts/20260226_oauth2_oidc/1/ — OAuth 2.0 / OIDC
• https://yuhi-sa.github.io/posts/20260226_zero_trust/1/ — ゼロトラスト
• https://yuhi-sa.github.io/posts/20260223_security_certs/1/ — セキュリティ資格比較

接続先ハブ

• https://yuhi-sa.github.io/posts/20260521_bode_plot/1/ — Bode 線図ハブ
• https://yuhi-sa.github.io/posts/20260522_filter_design_guide/1/ — フィルタ設計指針ハブ
• https://yuhi-sa.github.io/posts/20260522_monte_carlo_optimization/1/ — モンテカルロ最適化ハブ
• https://yuhi-sa.github.io/posts/20260524_time_frequency_guide/1/ — 時間周波数解析ハブ
• https://yuhi-sa.github.io/posts/20260525_ml_timeseries_guide/1/ — 機械学習時系列ハブ
• https://yuhi-sa.github.io/posts/20260613_discrete_dsp_basics/1/ — 離散 DSP 基礎ハブ
• https://yuhi-sa.github.io/posts/20260528_dsp_ml_roadmap/1/ — DSP/ML メタロードマップ

関連ツール（DevToolBox）

• ハッシュ生成ツール — MD5 / SHA-1 / SHA-256 / SHA-512 対応
• 進数変換ツール — 2 進数 / 8 進数 / 10 進数 / 16 進数
• Base64 エンコード／デコード — 暗号通信の前段で頻出

10. 困難性仮定の比較 — 安全性はどこから来て、何に壊れるのか

これまで見てきた各アルゴリズムは、同じ「暗号」という言葉でくくられていても、安全性の根拠がまったく異なる。この違いを横断的に整理することが、個別記事を読むだけでは得にくい本ハブ固有の価値である。

10.1 困難性仮定の一覧表

10.2 「困難性仮定を持つ」暗号と「解読耐性」の暗号の違い

RSA・DH・ECC は、**「もしこの数論的問題が解ければ暗号も破れる」という具体的な還元（reduction）**を持つ設計である。素因数分解や離散対数問題という、何十年も研究されてきた具体的な数学の未解決問題に安全性の根拠を委ねている。

一方 AES や SHA-256 には、こうした具体的な数学的困難性問題への還元は存在しない。SPN 構造や GF(2^8) 上の非線形変換（https://yuhi-sa.github.io/posts/20260703_aes_symmetric_crypto/1/ 参照）が差分解読法・線形解読法などの既知の攻撃手法すべてに対して経験的に耐性を持つ、という暗号解読コミュニティによる長年の検証が安全性の根拠になっている。これは弱い安全性ではなく、むしろ「攻撃者コミュニティ全体が四半世紀破れなかった」という実績に基づく安全性であり、RSA/DH/ECC とは種類が異なるだけである。

10.3 量子コンピュータ（Shor のアルゴリズム）の非対称な影響

Shor のアルゴリズムは、素因数分解と離散対数問題（有限体上・楕円曲線上のいずれも）を量子コンピュータ上で多項式時間で解く。これにより、RSA・DH・ECDH・ECDSA・EC-ElGamal は量子計算機が実用化されれば原理的にすべて解読可能になる。https://yuhi-sa.github.io/posts/20260715_post_quantum_lwe/1/が詳解する通り、これが LWE ベースの耐量子暗号への移行が進む理由である。

対称鍵暗号とハッシュ関数への影響は非対称に軽い。Grover のアルゴリズムは非構造化探索を平方根に加速するだけであり、AES-128 の実効鍵長は 64 bit（AES-256 なら 128 bit）に低下する（https://yuhi-sa.github.io/posts/20260703_aes_symmetric_crypto/1/）。128 bit の実効安全性は現在の基準（本記事 §6 の表）で十分な水準であるため、**「量子時代に備えるなら AES-256」**という指針こそあれ、対称鍵暗号自体の置き換えは必要ない。

LWE 問題には、Shor のアルゴリズムに相当する既知の効率的な量子アルゴリズムが存在しない。格子基底簡約（BKZ）は古典・量子のいずれでも次数に対しほぼ指数関数的なコストがかかると評価されており、これが ML-KEM / ML-DSA が「耐量子」を名乗る根拠になっている。

11. 実行検証 — 主要アルゴリズムの実測ベンチマーク

理論上の困難性仮定の違いは、実際の実行時間にも明確に現れる。ここでは cryptography ライブラリ（v49.0.0、Python 3.14.6、Apple M1、macOS）を使い、RSA・ECDSA・Ed25519・AES-GCM・X25519 を実際に実行して比較する。ベンチマークコードと生の実行結果は本記事末尾の環境情報の通りで、乱数を使う鍵生成のみ試行回数の中央値（median）を報告している。

11.1 鍵生成・署名・検証の実測比較

観測できる特徴は 3 点。

1. 鍵生成コストが数論的仮定の違いをそのまま反映する。 RSA は「大きな素数を 2 つ見つける」ために Miller–Rabin 試行を繰り返す必要があり、ECDSA / Ed25519 の鍵生成（乱数 1 個を選ぶだけ）より RSA-2048 で約 4,300 倍、RSA-3072 で約 10,200 倍遅い。本ブログの https://yuhi-sa.github.io/posts/20260225_rsa/1/ が実測した純粋 Python 実装（最適化ライブラリなし）では、鍵長 1024 bit の鍵生成に中央値 9,726.6 ms かかっており、それと比べると cryptography ライブラリ（GMP 相当の多倍長演算 + C 実装）は 2048 bit というより大きな鍵長でも 74.90 ms と 100 倍以上高速である。これは §5 で述べた「学習用実装と運用ライブラリの速度差」を実測で裏付ける結果である。
2. RSA は検証が速く署名が遅いという非対称性を持つ。 公開指数 \(e=65537\) （2進数で 1 のビットが 2 個）を使う羃乗剰余は 17 回程度の二乗で済むのに対し、秘密指数 \(d\) は 2048 bit 全域にわたるランダムな値なので約 2048 回の二乗が必要になる。これが RSA-2048 の検証（0.033 ms）と署名（1.067 ms）の間の約 32 倍の差になって表れている。ECDSA / Ed25519 にはこの非対称性がなく、署名と検証がほぼ同コストである。
3. ECDSA と Ed25519 は同格だが、Ed25519 の検証がやや遅い。 これは Ed25519 の検証が二重スカラー倍算（\([s]B = R + [h]A\) の確認）を要するためで、https://yuhi-sa.github.io/posts/20260704_digital_signature/1/ が指摘する「バッチ検証に最適化しやすい」という設計とはまた別の、単発検証コストの話である。

11.2 対称鍵暗号のスループットと鍵交換コストの実測比較

AES-128-GCM と AES-256-GCM のバルク暗号化スループット（64 MiB ペイロード、5 回実行の中央値）:

AES-256 はラウンド数が 14（AES-128 は 10）であるため理論上 40% 遅くなるはずだが、実測差は約 16% にとどまる。AES-NI 命令によるラウンド関数のハードウェアアクセラレーションが大部分のコストを均しているためで、「量子時代に備えて AES-256 を選ぶ」（§10.3）というコストはほぼ無視できることが実測で裏付けられる。

共有鍵確立の 1 セッションあたりコスト（RSA行は長期鍵を使い回す前提で鍵生成を除いた輸送コストのみ、X25519行はセッションごとに鍵を使い捨てる実運用を想定し両者の鍵生成を含む完全な交換コスト）:

X25519 は RSA-2048 鍵輸送より約 2.1 倍、RSA-3072 より約 5.4 倍高速である。加えて、RSA 鍵輸送は長期の RSA 鍵ペア（一度だけ生成すればよいが、生成コストは §11.1 の通り 75〜190 ms）をサーバー側に保持し続ける方式であるのに対し、X25519 は鍵生成自体が 0.017〜0.09 ms 相当（ECDSA P-256 鍵生成のコストと同オーダー）なのでセッションごとに使い捨て（ephemeral）にしても実用上のコストがほぼゼロである。これが TLS 1.3 が ECDHE を必須にし、静的 RSA 鍵輸送を廃止した実務上の理由の一つであり、https://yuhi-sa.github.io/posts/20260614_diffie_hellman/1/ が説明する**前方秘匿性（forward secrecy）**を実質コストゼロで実現できることを意味する。

12. どのアルゴリズムを使うべきか — ユースケース別の決定木

理論と実測を踏まえ、実務でよく遭遇する 5 つのユースケースに対する選択指針を整理する。

12.1 なぜパスワード保存に SHA-256 を使ってはいけないのか

本ハブが束ねる記事群は RSA・DH・ECC・AES・ハッシュ・署名・TLS を扱うが、パスワード保存だけは意図的にどの記事もカバーしていない。理由も含めて正しい文脈をここで補っておく。

SHA-256 のようなハッシュ関数は「入力から出力を計算するのは速く、逆算は困難」という一方向性を安全性の根拠にする（§段階 6）。ところがこの「速く計算できる」という性質こそが、パスワードのハッシュ化にはむしろ弱点になる。攻撃者がパスワードのハッシュ値を入手した場合、辞書攻撃や総当たり攻撃で候補パスワードを片っ端から SHA-256 にかけて比較すればよい。現代の GPU / ASIC は SHA-256 を毎秒数十億回計算できるため、よくあるパスワードの多くは数秒〜数分で割り出されてしまう。

bcrypt・scrypt・Argon2 はこの問題を、ハッシュ計算そのものを意図的に遅く・メモリ集約的にすることで解決する。bcrypt は Blowfish の鍵スケジュールを繰り返し適用するコストパラメータを持ち、scrypt と Argon2（2015 年の Password Hashing Competition 優勝方式）はさらに大量のメモリアクセスを要求する（メモリハード）ことで、並列化に強い GPU / ASIC 攻撃のコストパフォーマンスを大きく損なわせる。ソルト（ユーザーごとに異なるランダム値）を内蔵する設計も共通しており、レインボーテーブル攻撃も無効化する。「ハッシュ関数の安全性 = 一方向性」と「パスワードハッシュの安全性 = 意図的な低速性」は別の要件であり、両者を混同しないことが重要である。

13. 最新動向 — NIST PQC 標準化の現状

https://yuhi-sa.github.io/posts/20260715_post_quantum_lwe/1/ が詳解する通り、NIST は 2024 年 8 月に FIPS 203（ML-KEM、鍵カプセル化）・FIPS 204（ML-DSA、署名）・FIPS 205（SLH-DSA、ハッシュベース署名）を正式に確定した。続く2025 年 3 月には、格子問題とは異なる数学的構造（誤り訂正符号）に基づく HQC（Hamming Quasi-Cyclic）を、ML-KEM のバックアップとなる 5 番目の PQC アルゴリズムに選定しており、Draft 標準は 2026 年頃、最終確定は 2027 年を見込む( NIST News, 2025年3月11日 )。

本記事執筆時点での更新として、NIST は 2025 年 8 月、格子ベースの署名方式 FN-DSA（旧名 FALCON）の公開ドラフトを FIPS 206 として提出している。ML-DSA（Dilithium）よりも署名サイズが小さいことが特徴で、レビュー期間は他の PQC 標準と同様に約 1 年を見込むため、最終確定は 2026 年後半から 2027 年前半になる見通しである（ DigiCert, “Quantum-Ready FN-DSA (FIPS 206) Nears Draft Approval from NIST” 、 NIST CSRC, FIPS 206 プレゼンテーション ）。主要な認証局は、標準が最終確定するまで FN-DSA を本番投入しない方針を表明しており、現時点での実務的な選択は引き続き ML-KEM（鍵交換）+ ML-DSA または SLH-DSA（署名）の組み合わせである。

暗号は数学・アルゴリズム・実装ライブラリ・プロトコルが層を成す領域である。本ハブを起点として、自分の興味とゴールに合うレベルから読み進めてほしい。

おすすめ書籍

古典暗号から共通鍵・公開鍵暗号、ハッシュ関数、デジタル署名、SSL/TLSまでを平易な文章と図解で解説した定番の日本語入門書です。本ロードマップ全体の地図として最初に読むのに適しています。

※ 上記は Amazon アソシエイトのリンクです。