🔖 キーワード索引

「公開鍵暗号（public-key cryptography）」は情報セキュリティの中核概念のひとつ。 本ページでは公開鍵暗号を取り巻く中核キーワードを以下にチップで一覧化する。 各キーワードは関連する概念・手法・道具立てを含み、 文献検索や学習計画の起点になる。

これらのキーワードは「公開鍵暗号の理解 → 適用 → 検証」のプロセスを構成する。 各章で詳しく解説する。

🎨 直感で掴む

「南京錠とその鍵」の比喩が直感的：

• 公開鍵 = 開いた南京錠：誰でも入手OK。 これで箱をロックできる
• 秘密鍵 = 唯一の鍵：本人だけが持つ。 これでしかロック解除できない

Alice が Bob に秘密メッセージを送るなら：

1. Alice は Bob の公開南京錠を入手
2. メッセージを箱に入れて Bob の南京錠でロック
3. 送る
4. Bob は自分の鍵で開ける

途中で誰が見ても、 南京錠は開けられないので安全。 これが共通鍵暗号（同じ鍵で施錠／解錠）と決定的に違う点。

多数の拠点が相互に暗号通信する状況を考えるとイメージしやすい。 拠点 A が拠点 B に機密レポートを送るとき、 共通鍵方式だと「相手ごとの鍵を事前にすべて配布」する必要があり、 参加者が増えるたびに鍵交換のコストが急増する（n 人なら約 n²/2 本の鍵）。 公開鍵方式なら、 各拠点は「自分の公開鍵を一度だけ公開しておく」ことで、 誰からでも安全に暗号化されたデータを受け取れる。 必要な鍵の数が O(n²) → O(n) に下がる、 これがインターネット規模の通信が成立する数学的基盤である。

セキュリティの根源は「素因数分解の困難性 (RSA)」または「離散対数問題 (楕円曲線)」にある。 たとえば n = 15 = 3 × 5 を分解するのは即座にできるが、 n が 2048 bit (約 617 桁) になると最新のスーパーコンピュータでも宇宙の年齢を超える時間がかかる。 公開鍵 (n, e) は誰でも見られるが、 そこから秘密鍵 d を逆算するには n の素因数分解が必須 — この「掛け算は簡単だが逆算は不可能」という非対称性こそが、 鍵を公開しても安全である理由である。

📐 定義／数式

📐 ECC（楕円曲線暗号）の仕組み

楕円曲線 $y^2=x^3+ax+b$ 上の点同士の「加法」を定義し、 これを使って公開鍵暗号を構築します。 「点のスカラー倍 $kP$ を計算するのは簡単、 でも結果から $k$ を逆算するのは難しい」（楕円曲線離散対数問題）が根拠。

主な利点：鍵長が短い。 RSA 3072 bit ≈ ECC 256 bit、 RSA 15360 bit ≈ ECC 521 bit という換算。 同じ安全性を 1/10 〜 1/30 の鍵長で実現できる。 これは IoT・モバイル機器で計算資源とバッテリーを節約できるため、 現代の標準です。

主要な曲線：secp256r1（NIST P-256）、 secp256k1（Bitcoin で使用）、 Curve25519（Ed25519 署名・X25519 鍵交換）、 Curve448。 米国 NIST の標準と、 IETF 標準の safe curves 系で派閥が分かれています。

⚛ ポスト量子暗号（PQC）

量子コンピュータが実用化されると、 Shor のアルゴリズム により RSA も ECC も多項式時間で破られます。 そこで 耐量子計算機暗号（Post-Quantum Cryptography, PQC）の研究が活発です。

NIST が標準化を進めている PQC 候補：

• CRYSTALS-Kyber（鍵カプセル化、 格子ベース）── 2024 年に標準化
• CRYSTALS-Dilithium（署名、 格子ベース）── 2024 年に標準化
• FALCON（署名、 格子ベース、 短い署名）
• SPHINCS+（署名、 ハッシュベース、 保守的）
• BIKE, HQC（符号ベース、 候補）

既存のデータを将来の量子計算機に解読されないよう、 今のうちから 重要データを PQC で暗号化しておく 「ハーベスト・ナウ、 デクリプト・レイター」 の脅威も語られています。 実務でも 2030 年以降は PQC が標準になるでしょう。

📐 RSA の数論的背景：オイラーの定理とフェルマーの小定理

RSA の安全性は 古典数論 の定理に基づきます。 順を追って整理します。

フェルマーの小定理

$$a^{p-1}\equiv 1\pmod p,\quad \text{ただし}p\text{は素数で}\gcd(a,p)=1$$

17 世紀にフェルマーが発見。 「素数 $p$ で割った余りの世界では、 $a^{p-1}$ は常に 1 に等しい」。 素数性の判定や暗号の正当性証明の出発点。

オイラーの定理（一般化）

$$a^{\phi(n)}\equiv 1\pmod n,\quad \text{ただし}\gcd(a,n)=1$$

$\phi(n)$ はオイラーのトーシェント関数で、 「$n$ 未満で $n$ と互いに素な整数の個数」。 $n$ が素数なら $\phi(n)=n-1$（フェルマーの特殊形）。 $n=pq$（$p,q$ 素数）なら $\phi(n)=(p-1)(q-1)$。

RSA の正当性

$$ed\equiv 1\pmod{\phi(n)}\Rightarrow M^{ed}\equiv M\pmod n$$

$ed = 1 + k\phi(n)$ なので、 $M^{ed}=M^{1+k\phi(n)}=M\cdot (M^{\phi(n)})^k\equiv M\cdot 1^k\equiv M\pmod n$。 これで「暗号化 → 復号で元の $M$ に戻る」が保証されます。

📐 「難しさ」を計算量で定量化

RSA 2048 bit の因数分解は、 既知の最良アルゴリズム（一般数体ふるい GNFS）の計算量が $O(\exp((\frac{64}{9})^{1/3}(\log n)^{1/3}(\log\log n)^{2/3}))$。 2048 bit のとき、 およそ $2^{112}$ 回の演算が必要。

仮に 1 GHz の計算機で 1 ns で 1 演算できるとして、 $2^{112}=5.2\times 10^{33}$ 演算には $5.2\times 10^{24}$ 秒、 これは宇宙の年齢の $10^{14}$ 倍。 地球上の全 CPU（推定 $10^{20}$ 個）を集めても $5\times 10^{4}$ 年。 つまり、 古典計算機では実質的に不可能。

一方、 量子計算機の Shor のアルゴリズムは $O((\log n)^3)$ の多項式時間。 2048 bit でも数時間で因数分解可能と見積もられています。 これが PQC への移行が急がれる理由。

🔬 数式を言葉で読み解く

🔬 数式を言葉で読み解く（500 字超の精読）

RSA の中心式 $C=M^e \bmod n$ と $M=C^d \bmod n$ を、 記号一つひとつ言葉に翻訳します。

まず $M$（plaintext, 平文）は 「秘密にしたいデータ」を整数表現にしたもの。 たとえば「HELLO」というメッセージは ASCII で $0x48656C6C6F$ という整数。 これがそのまま 5 バイトの整数として扱われます。 $0 \le M < n$ という制約があり、 メッセージが $n$ より大きいときはブロック分割します。

次に $e$（exponent, 公開指数）は 「公開鍵の片割れ」。 慣例では $e=65537=2^{16}+1$。 これは「2 のべき乗 + 1」の形なので、 暗号化の繰り返し二乗計算が速い。 そして $n$ は $p$ と $q$ という 2 つの巨大素数の積で、 モジュラス（剰余） と呼ばれる。 これも公開鍵の一部。

演算 $\bmod n$ は 「$n$ で割った余り」。 これにより結果は必ず $0$ から $n-1$ の範囲に収まる。 $M^e$ をそのまま計算すると桁数が爆発しますが、 各ステップで $\bmod n$ を取れば数百桁の数の演算で済みます。 これが 繰り返し二乗法（square-and-multiply）の計算量削減トリック。

復号式 $M=C^d \bmod n$ の $d$ は 「秘密鍵」。 $d=e^{-1} \bmod \phi(n)$ を満たす唯一の整数で、 $\phi(n)=(p-1)(q-1)$ はオイラーのトーシェント関数。 オイラーの定理 $a^{\phi(n)}\equiv 1 \pmod n$ から、 $C^d = M^{ed}=M^{1+k\phi(n)}\equiv M \pmod n$ が成立し、 元の $M$ が復元される。

この式の 不可逆性 は「$n=pq$ を素因数分解できない限り $\phi(n)$ が分からず、 $d$ も求められない」という 計算量的困難性 に依拠します。 2024 年現在、 既知の最速因数分解アルゴリズム（一般数体ふるい）でも、 2048 bit RSA を破るには地球上のすべての計算資源を集めても何百年もかかると見積もられています。

🔬 データ分析で PKC を使う完全性・再現性の担保

データ分析で 「分析の再現性」 を確保するための PKC 活用：

1. 使用データの完全性証明：統計データCSV のダウンロード時点で SHA-256 ハッシュを記録し、 配布元の公開ハッシュと一致することを確認。 レポートに記載。
2. コードの真正性：分析コードを Git で管理し、 各コミットを Ed25519 署名。 「いつ・誰が・何を書いたか」が改ざん不可能に。
3. 結果の確定：分析結果ファイルを PGP で署名し、 提出時刻のタイムスタンプ局署名を追加。 後から「結果を改ざんしていない」ことを証明可能。
4. 共同研究者間の交換：個票データを扱う場合は受信者の公開鍵で暗号化、 復号後は速やかに消去。

このような 科学的厳密性 を担保する仕組みは、 PKC があるからこそ可能。 統計分析の信頼性向上に直結します。

🧮 実値で計算してみる

RSA の暗号化・復号を小さな数で手計算する。 数式 $$C \equiv M^e \pmod{N}, \quad M \equiv C^d \pmod{N}$$

入力ベクトル（素数ペアと平文を数値リストとして与える）: [p, q, M] = [11, 13, 42]、 公開指数 e = 7。 この 3 値から $N, \phi(N), d$ を導出し、 暗号化 $C$ → 復号 $M'$ が $M'=M$ になることを確認する。

使う数値（$p=11, q=13$）

手計算ステップ（平文 $M = 42$）

このコードでやること：$p=11, q=13$ の RSA で手計算結果と Python の pow(M, e, N) が一致することを確認する。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

p, q = 11, 13
n = p * q          # 143
phi = (p-1)*(q-1)  # 120
e = 7
d = pow(e, -1, phi)  # 103

M = 42
C = pow(M, e, n)   # 暗号化
M2 = pow(C, d, n)  # 復号

print(f"N={n}, phi={phi}, e={e}, d={d}")
print(f"暗号化: {M} -> {C}")
print(f"復号:   {C} -> {M2}")
assert M == M2
print("手計算と一致")

💬 Step 2 の手計算 C=81 と Python 出力が完全一致。 Step 3 の復号も M=42 に戻り、 $M^{ed} \equiv M \pmod{N}$ が成立することが確認された。 実用では $N$ が 2048bit（617桁の10進数）。 現在のスパコンでは因数分解に数千年級かかる。

🔐 もっと深く ── ハイブリッド方式の理由

RSA 2048bit は一度に暗号化できるのが約 245 バイトに限られる。 公的な 564 行 × 112 列の CSV（数 MB） は直接暗号化できない。 そこで AES（共通鍵）で本文、 RSA で AES 鍵だけ を暗号化する ハイブリッド方式 が標準。

耐量子暗号への移行

量子コンピュータの Shor のアルゴリズムは、 多項式時間で素因数分解を解く。 RSA／ECC は将来破られる前提で、 NIST が CRYSTALS-Kyber（鍵交換）と Dilithium（署名）を 2024 年に標準化。 行政データの長期保管では、 今のうちから PQC への移行計画を立てる必要がある。

🧮 統計データCSV 流通シナリオ：4 場面で PKC

公的統計データの配布・流通の各場面で PKC がどう機能するかを 4 シナリオで示します。

シナリオ A：HTTPS でダウンロード

統計データ配布サイトからのダウンロードは TLS（HTTPS）。 ① ブラウザがサーバ証明書を取得、 ② サーバの公開鍵を使って セッション鍵 を ECDHE で合意、 ③ 以降は AES でデータ転送。 「サーバの公開鍵」が本物かは認証局（DigiCert, Let's Encrypt など）の署名で検証。

シナリオ B：ファイル整合性検証

statistics.csv のダウンロード後、 配布元の SHA-256 ハッシュ と比較。 ハッシュは「ファイルの指紋」で、 1 ビットでも変われば値が変わる。 配布元がハッシュ値をデジタル署名していれば、 PKC で「正規の配布元が配布した正しいファイル」であることが確認できる。

シナリオ C：研究者間でのデータ共有

統計データCSV から派生して構築した研究データセットを共同研究者に送る場合、 GPG で暗号化。 ① 相手の公開鍵で AES セッション鍵を暗号化、 ② AES でファイル本体を暗号化、 ③ 両方をまとめて送信。 受信者は秘密鍵で AES 鍵を復号し、 ファイルを復元できる。 これが ハイブリッド暗号 の典型。

シナリオ D：提出ファイルの署名

提出物に デジタル署名 を付けると、 「いつ、 誰が、 何を提出したか」が改ざん不可能な形で証明できる。 提出者は自分の秘密鍵で署名、 検証者は提出者の公開鍵で検証。 タイムスタンプサーバを併用すれば「提出時刻の改ざん」も防げる。

🧮 拡張ユークリッド互除法による逆元計算

RSA の鍵生成では $d=e^{-1} \bmod \phi(n)$ を計算する必要があり、 これに 拡張ユークリッド互除法 を使います。

アルゴリズム：$\gcd(a,b)$ を求めつつ、 $ax+by=\gcd(a,b)$ を満たす整数 $x,y$ も同時に求める。 $\gcd(e,\phi)=1$ のときに $ex+\phi y=1$ となる $x$ が見つかり、 $d=x \bmod \phi$ が乗法逆元。

1
2
3
4
5
6
7
8

def ext_gcd(a, b):
    if b == 0: return a, 1, 0
    g, x1, y1 = ext_gcd(b, a % b)
    return g, y1, x1 - (a // b) * y1

g, x, _ = ext_gcd(17, 3120)   # e=17, phi=3120
d = x % 3120
print(f'd = {d}')   # 2753

🎲 大きな素数の生成

RSA 2048 bit には 1024 bit の素数 $p, q$ が 2 つ必要。 これをどう生成するか？

1. 乱数生成：暗号学的に強い乱数生成器（CSPRNG）で 1024 bit の整数を生成。
2. 奇数化：偶数なら +1。 末尾 2 ビットを 11 にして「3 で割って余りが 0 ではない」候補に。
3. 小さな素数で篩：3, 5, 7, ..., 1000 程度の素数で割って候補を絞る。
4. Miller-Rabin 素数性テスト：確率的素数判定。 40 回テストして全部 OK なら素数（誤判定確率 $4^{-40}\approx 10^{-24}$）。
5. 追加検証：強い素数（safe prime, strong prime）の条件を満たすか確認。

PC で 2048 bit RSA 鍵生成に数秒かかるのは、 この素数探索ループが回っているため。 IoT のような非力なデバイスでは ECC の方が現実的です。

🔢 ハッシュ関数と PKC の協奏

デジタル署名では、 巨大なファイル全体を直接 RSA 署名するのではなく、 ハッシュ値 に対して署名します。 ハッシュ関数（SHA-256 等）はファイルの「指紋」を 256 bit 固定長で生成し、 これを RSA で署名する。

ハッシュに必要な性質：① 原像困難性（出力から入力を逆算不可能）、 ② 第二原像困難性（同じ出力を持つ別の入力を見つけられない）、 ③ 衝突困難性（同じ出力の任意の 2 入力ペアが見つからない）。 SHA-1 は ③ が破れたため非推奨に、 SHA-2 / SHA-3 が標準。

統計データCSV の配布ファイルでも、 配布元が SHA-256 ハッシュを公開し、 利用者がダウンロード後にハッシュを照合する運用が標準。 これは PKC ではないが、 PKC の前提となる 信頼インフラ の一部です。

🔑 秘密鍵の管理：実務上のベストプラクティス

PKC の安全性は 「秘密鍵を漏らさない」 に尽きます。 実務での鍵管理：

• HSM（Hardware Security Module）：専用ハードウェアで秘密鍵を物理的に保護。 ハードウェア外に取り出せない構造。
• TPM（Trusted Platform Module）：PC・スマホ内蔵のセキュリティチップ。 個人用 PKI のローカル保管。
• KMS（Key Management Service）：クラウドの鍵管理サービス。 AWS KMS、 Google Cloud KMS、 Azure Key Vault。
• パスフレーズ保護：秘密鍵ファイルを AES で暗号化。 GnuPG では gpg --gen-key でパスフレーズ必須。
• 鍵ローテーション：定期的（年 1 回程度）に鍵を更新。 旧鍵で復号できる移行期間を設ける。
• 分散管理（Shamir 秘密分散）：秘密鍵を $n$ 分割し、 $k$ 個以上集めると復元可能。 ルート CA 鍵で常用。

個人レベルでは、 GPG キーペアを作って ~/.gnupg/ に保存、 パスフレーズで保護、 という運用で十分。 研究室レベルでは PKI を組み、 大学全体の認証基盤と統合するケースもあります。

🔐 PGP/GPG の実践運用

PGP（Pretty Good Privacy）は 1991 年に Phil Zimmermann が公開した暗号メールソフト。 オープンソース版が GnuPG（GPG）。 実務で共同研究者にデータを送るときの定番ツールです。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20

# 鍵生成
gpg --gen-key

# 公開鍵を相手にエクスポート
gpg --export -a "user@example.com" > my_pub.asc

# 相手の公開鍵をインポート
gpg --import their_pub.asc

# ファイル暗号化（相手の公開鍵で）
gpg -e -r "their_email" sensitive_data.csv

# ファイル復号（自分の秘密鍵で）
gpg -d sensitive_data.csv.gpg > sensitive_data.csv

# 署名作成
gpg --sign --armor 公的統計データ-analysis-report.pdf

# 署名検証
gpg --verify 公的統計データ-analysis-report.pdf.asc

これらコマンドの裏では、 RSA や Ed25519 などの PKC アルゴリズムが動いています。 ユーザは数学的詳細を知らなくても、 安全な通信ができる。 これが 暗号の民主化。

🕸 Web of Trust vs 階層型 PKI

公開鍵の真正性を担保する 2 つのモデル：

商用 Web 通信は階層型、 個人間メール暗号化は Web of Trust が多い。 実務で自分の公開鍵を 署名イベント（key signing party） で他研究者に署名してもらうと、 Web of Trust が構築できます。

🖥 SSH の鍵認証も PKC

研究計算サーバへのリモート接続で使う SSH 公開鍵認証 も PKC の応用。 パスワード認証よりはるかに安全です。

1
2
3
4
5
6
7
8

# Ed25519 鍵生成（推奨）
ssh-keygen -t ed25519 -C "your_email@example.com"

# 鍵をサーバに登録
ssh-copy-id user@server.example.com

# 鍵認証で接続
ssh user@server.example.com

~/.ssh/ 配下の id_ed25519（秘密鍵）と id_ed25519.pub（公開鍵）の管理が重要。 秘密鍵に 600 権限を設定し、 必ずパスフレーズで保護。 ssh-agent でメモリに展開すれば、 入力は一度きりで済みます。

⛓ ブロックチェーンと PKC の融合

ビットコイン・イーサリアム等のブロックチェーンでは、 各取引が秘密鍵で署名 されます。 公開鍵（から導出されるアドレス）がアカウントの ID。 これにより「中央銀行不要の通貨」が成立。

使われる暗号は ECDSA on secp256k1。 RSA は遅すぎてブロックチェーンには不向き。 鍵長 256 bit で十分な安全性、 署名長 64 bit という効率性が選ばれた理由。

実務で 研究データの長期保存 にブロックチェーンを使う研究も進行中。 「タイムスタンプの改ざん不可能性」が PKC + ブロックチェーンで担保されます。

✅ 学習チェックリスト

• □ 公開鍵と秘密鍵の役割の違いを 1 分で説明できる
• □ RSA の暗号化・復号の数式を書ける（$C=M^e \bmod n$、 $M=C^d \bmod n$）
• □ ハイブリッド暗号（RSA + AES）が必要な理由を説明できる
• □ 中間者攻撃と PKI による防御の流れを理解している
• □ Diffie-Hellman 鍵交換と RSA の違いを言える
• □ デジタル署名の作成・検証フローを説明できる
• □ RSA と ECC の鍵長換算（3072 bit ≈ 256 bit ECC）を知っている
• □ ポスト量子暗号（PQC）の必要性を理解している
• □ Python の cryptography ライブラリで鍵生成・暗号化・署名ができる
• □ 公的データ流通における PKC の役割を言える

🔗 同カテゴリ（情報セキュリティ）の用語

• 情報セキュリティ — 全体俯瞰
• 暗号化 — PKC の上位
• 認証 — PKC で実現
• サイバーセキュリティ — 防御の体系
• マルウェア — 攻撃側技術
• 盗聴 — PKC で防ぐ脅威
• なりすまし — PKC で防ぐ脅威
• 機密性 — PKC が守る性質
• 可用性 — PKC で支える性質
• アクセス管理 — PKC + 認可

📔 PKC マイクロ用語集

📖 さらに学ぶための文献

• 『暗号技術入門 第 3 版』結城浩, SB Creative — 日本語の名著
• B. Schneier『Applied Cryptography』Wiley — 古典的教科書
• 『現代暗号への招待』黒澤馨ほか, サイエンス社 — 数論ベースの解説
• 『暗号理論』J. Katz & Y. Lindell, 共立出版 — 厳密な理論書
• RFC 8017『PKCS #1: RSA Cryptography Specifications v2.2』— RSA の規格
• NIST SP 800-56A — 鍵確立の規格
• NIST FIPS 186-5 — デジタル署名標準
• 『ポスト量子暗号』情報処理学会, 共立出版

🎯 ページ全体の最終要点

1. PKC は 公開鍵 / 秘密鍵 の対を使い、 鍵配送問題を数学的に解決した革命的技術。
2. RSA は 大整数の因数分解困難性、 ECC は 楕円曲線離散対数問題の困難性 に依拠。
3. 実運用は RSA / ECC + AES の ハイブリッド暗号。 鍵交換は PKC、 本体は対称暗号で高速化。
4. 公的統計データの配布も、 HTTPS や PGP 署名で PKC を間接利用。
5. 量子計算機時代に備え、 PQC（耐量子計算機暗号） への移行が始まっている。
6. 「鍵管理が PKC のすべて」── 秘密鍵を守らなければ意味が無い。 HSM, パスフレーズ, ローテーション。

📡 TLS 暗号スイートの分解

TLS 1.2 までの暗号スイート名は TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 のような構造。 分解すると：

TLS 1.3 では大幅に整理され、 暗号スイートは AEAD（認証付き暗号）と HKDF（鍵導出）のペアだけに簡素化。 セキュリティの脆弱な選択肢が削除されました。

🏛 日本の GPKI／LGPKI

GPKI（政府認証基盤）は中央省庁向けの公開鍵基盤、 LGPKI（地方公共団体組織認証基盤）は地方自治体向け。 統計データ配布にも、 こうした PKI が背後で動いています。

マイナンバーカードには JPKI（公的個人認証サービス） の電子証明書が格納され、 e-Tax や e-Gov での電子申請に使われます。 これらは政府が認証局となる階層型 PKI で、 国民全員に向けた巨大な PKC 運用の例。

🧭 2026 年時点の推奨アルゴリズム

CRYPTREC（電子政府推奨暗号リスト）や NIST SP 800-131A も併せて確認しましょう。 推奨は 5 年スパン で見直されるので、 古い文献を鵜呑みにしない注意も必要。

🎭 ゼロ知識証明（ZKP）への発展

PKC の応用として、 「秘密を明かさずに証明する」 技術が ZKP。 たとえば「年齢が 20 歳以上である」ことを生年月日を明かさずに証明する、 「銀行口座残高が十分」を残高額を明かさずに証明する。

ZKP は 1985 年に Goldwasser, Micali, Rackoff が提案。 現代では zk-SNARK・zk-STARK といった非対話型 ZKP が、 ブロックチェーン（Zcash、 zkSync）・プライバシー保護機械学習・電子投票で実用化されています。

統計分野では、 公的な 個票データを開示せずに統計量を共同計算 する「秘密分散・秘密計算」が ZKP と関連します。 これにより複数自治体が個人情報を漏らさず共同統計分析できる、 という未来が見えてきています。

🧮 数式に値を入れて手で計算する: RSA の小例

合成 (p=11, q=13) で公開鍵・秘密鍵を生成する。

Step 1: パラメータ

Step 2: 鍵

Step 3: 暗号化

🐍 Python で再現

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

p, q = 11, 13
n = p * q
phi = (p-1) * (q-1)
e = 7
d = pow(e, -1, phi)
m = 5
c = pow(m, e, n)
m_back = pow(c, d, n)
print(f"n: {n}, φ: {phi}, d: {d}")
print(f"暗号: {c}, 復号: {m_back}")

📤 実行結果

💬 手計算 (Step 3) と Python 出力が完全一致。

🎮 手を動かして体感する

この章は「暗号化」ページ（共通鍵 vs 公開鍵の対比・シーザー暗号）とは重複しない、 公開鍵暗号ならではの2つの核心 ——「鍵交換」と「一方向性」—— を、 色を混ぜたり数を動かしたりして体で掴むミニ実験室です。 数式の裏づけはすべて上の章にあります。 （外部ライブラリ不要・オフライン動作・スマホのタッチ操作対応）

🎨 (a) 鍵交換を「色の混合」で体感 ── Diffie-Hellman

2人が公開の通信路だけを使い、 盗聴者に知られずに同じ「共有色（＝共通鍵）」へ到達できるか？ 各自が秘密の色を選び、 「共通色に混ぜて交換 → 受け取った混合色に自分の秘密色を足す」だけで、 双方が同じ色にたどり着きます。 混ぜるのは簡単・分離は困難という一方向性が目で分かります。

注意（アナロジーの限界）：色では「混合色 ÷ 共通色」で秘密色を割り戻せてしまいます。 本物の Diffie-Hellman は色の混合ではなく $g^x \bmod p$（下の (b)） を使い、 この「割り戻し」＝離散対数が計算的に不可能だからこそ安全です。 色はあくまで直感の入口です。

🔒 (b) 一方向性を体感 ── 離散対数 $g^x \bmod p$

$g=5,\ p=23$ で、 スライダー（またはグラフを指でドラッグ）で指数 $x$ を動かすと、 $y=5^x \bmod 23$ がピョンピョンと予測不能に跳ねます。 順方向（$x$→$y$）は一瞬。 でも逆方向（$y$→$x$）は総当りしかない ── これが一方向性の正体です。

小さな $p=23$ なら総当りは一瞬ですが、 実際の $p$ は約 600 桁。 総当り回数が天文学的になり、 順方向は簡単なのに逆方向は事実上不可能 ── この非対称性が鍵を公開しても安全な理由です。

🔑 (c) 公開鍵で施錠・秘密鍵で解錠

小さな RSA（$N=143,\ e=7,\ d=103$）で、 公開鍵 $e$ で暗号化した数は、 対応する秘密鍵 $d$ でしか元に戻らないことを確かめます。 スライダーで数値データ $M$（例：ID や集計値）を選んでください。 誤った鍵では復号できません。

💡 直感・落とし穴・発展

🐍 Python 実装

最小限のスニペットで動作確認できる例。 公的データを想定しています。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

# 公開鍵暗号は cryptography ライブラリで実装
from cryptography.hazmat.primitives.asymmetric import rsa, padding
from cryptography.hazmat.primitives import hashes

# 鍵ペア生成
priv = rsa.generate_private_key(public_exponent=65537, key_size=2048)
pub  = priv.public_key()

msg = b"top secret"
ct  = pub.encrypt(msg, padding.OAEP(mgf=padding.MGF1(hashes.SHA256()),
                                    algorithm=hashes.SHA256(), label=None))
pt  = priv.decrypt(ct, padding.OAEP(mgf=padding.MGF1(hashes.SHA256()),
                                    algorithm=hashes.SHA256(), label=None))
print(pt)  # b'top secret'  暗号→復号で復元

🌍 実応用シナリオ — 公的データ流通における公開鍵暗号

公開鍵暗号は単独で使うものではなく、 共通鍵・ハッシュ・署名と組み合わせた「プロトコル」として機能する。 統計データCSV を扱う実務での典型ユースケースを整理する。

統計データCSV は公開データなので暗号化は不要だが、 加工途中の中間ファイル（個票推定や独自集計）には機密性が必要なケースが出てくる。 また、 改ざん検知（完全性）と配布元の証明（真正性）には署名が不可欠で、 これは事実上公開鍵暗号の応用。 公的統計を扱う組織では NICT/IPA の暗号リスト（CRYPTREC）に準拠することが推奨される。

🐍 Python：RSA を手作りで実装（教育用）

小さな素数で RSA 鍵生成・暗号化・復号を手書き。 教育目的のみ、 実運用には cryptography ライブラリを使うこと。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

def gcd(a, b):
    while b: a, b = b, a % b
    return a

def modinv(e, phi):
    # 拡張ユークリッド互除法
    def ext(a, b):
        if b == 0: return (a, 1, 0)
        g, x, y = ext(b, a % b)
        return (g, y, x - (a // b) * y)
    g, x, _ = ext(e, phi)
    return x % phi

# 鍵生成
p, q = 61, 53
n = p * q
phi = (p - 1) * (q - 1)
e = 17
assert gcd(e, phi) == 1
d = modinv(e, phi)
print(f'公開鍵 (n={n}, e={e})')
print(f'秘密鍵 d={d}')

# 暗号化・復号
M = 65   # たとえば 'A' の ASCII
C = pow(M, e, n)
M2 = pow(C, d, n)
print(f'平文={M}, 暗号文={C}, 復号={M2}')

この実装は教育用で、 実運用には cryptography や pycryptodome ライブラリを使います。 OAEP パディング・乱数生成・サイドチャネル対策など多数の 細かな安全策 が組み込まれているため。

🐍 Python：実運用での RSA（cryptography）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34

from cryptography.hazmat.primitives.asymmetric import rsa, padding
from cryptography.hazmat.primitives import hashes, serialization

# 鍵生成（2048 bit, e=65537）
private_key = rsa.generate_private_key(public_exponent=65537, key_size=2048)
public_key = private_key.public_key()

# 公開鍵を PEM 形式で出力
pem_pub = public_key.public_bytes(
    encoding=serialization.Encoding.PEM,
    format=serialization.PublicFormat.SubjectPublicKeyInfo
)
print(pem_pub.decode())

# 平文（統計データのメタデータを想定）
message = b'statistical dataset, 47 prefectures, 2026 edition'

# OAEP パディング付き暗号化
ciphertext = public_key.encrypt(
    message,
    padding.OAEP(mgf=padding.MGF1(algorithm=hashes.SHA256()),
                 algorithm=hashes.SHA256(),
                 label=None)
)

# 復号
plaintext = private_key.decrypt(
    ciphertext,
    padding.OAEP(mgf=padding.MGF1(algorithm=hashes.SHA256()),
                 algorithm=hashes.SHA256(),
                 label=None)
)
assert plaintext == message
print('復号成功:', plaintext.decode())

🐍 Python：デジタル署名でファイル整合性確認

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34

from cryptography.hazmat.primitives.asymmetric import rsa, padding
from cryptography.hazmat.primitives import hashes
from cryptography.exceptions import InvalidSignature
import hashlib

# 鍵生成
key = rsa.generate_private_key(public_exponent=65537, key_size=2048)
pub = key.public_key()

# statistics.csv のハッシュを計算（実ファイル想定）
with open('data/raw/statistics.csv', 'rb') as f:
    file_hash = hashlib.sha256(f.read()).digest()

# 署名作成
signature = key.sign(
    file_hash,
    padding.PSS(mgf=padding.MGF1(hashes.SHA256()),
                salt_length=padding.PSS.MAX_LENGTH),
    hashes.SHA256()
)
print(f'Signature length: {len(signature)} bytes')

# 検証（受信者側）
try:
    pub.verify(
        signature,
        file_hash,
        padding.PSS(mgf=padding.MGF1(hashes.SHA256()),
                    salt_length=padding.PSS.MAX_LENGTH),
        hashes.SHA256()
    )
    print('検証成功：ファイルは改ざんされていません')
except InvalidSignature:
    print('検証失敗：ファイルが改ざんされた可能性あり')

実務で、 統計データCSV を分析する前に ファイル整合性 を確認する典型コード。 配布元が公開している SHA-256 ハッシュ値や PGP 署名と照合することで、 改ざんなくダウンロードできたか確認できます。

🤝 TLS ハンドシェイクのフロー

統計データ配布サイトに HTTPS でアクセスしたとき、 ブラウザとサーバの間で起こることを順を追って示します。

1. ClientHello：ブラウザがサポートする TLS バージョン・暗号スイート・乱数を送信。
2. ServerHello + 証明書：サーバは選択した暗号スイート・乱数・X.509 証明書を返す。 証明書には公開鍵と CA の署名が含まれる。
3. 証明書検証：ブラウザは内蔵された CA リストで証明書チェーンを検証。
4. 鍵交換：ECDHE で セッション鍵 を生成。 サーバ・クライアント双方が同じ鍵を持つ。
5. 暗号化通信開始：以降は AES-GCM 等の対称暗号でやりとり。

TLS 1.3 ではハンドシェイクが 1-RTT（往復 1 回）に最適化され、 さらに 0-RTT（再接続時）が選べる。 PKC のおかげで、 私たちは毎日意識せずに安全な Web 通信を享受しています。

🏛 PKI（公開鍵基盤）の階層

PKC を社会インフラとして運用する仕組みが PKI。 信頼の連鎖を以下のように構築します。

1. Root CA：最上位の認証局。 自分自身を署名（self-signed）。 OS・ブラウザに事前に内蔵される。
2. Intermediate CA：Root が署名する中間認証局。 実運用ではここから証明書を発行。
3. End-Entity 証明書：Web サーバ・個人・組織の証明書。 Intermediate が署名。
4. CRL / OCSP：失効した証明書の管理。 漏洩した秘密鍵に対応する公開鍵を無効化。

日本では 政府認証基盤（GPKI） や 地方公共団体組織認証基盤（LGPKI） が運用され、 公的な電子文書のやり取りに使われています。 統計データ配布も、 究極的にはこのような信頼の連鎖の上に成り立ちます。

🐍 Python：Ed25519 で軽量署名

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

from cryptography.hazmat.primitives.asymmetric.ed25519 import Ed25519PrivateKey
from cryptography.hazmat.primitives import serialization
from cryptography.exceptions import InvalidSignature

# 鍵生成
private_key = Ed25519PrivateKey.generate()
public_key = private_key.public_key()

# PEM 形式に出力
pem_priv = private_key.private_bytes(
    encoding=serialization.Encoding.PEM,
    format=serialization.PrivateFormat.PKCS8,
    encryption_algorithm=serialization.NoEncryption()
)
pem_pub = public_key.public_bytes(
    encoding=serialization.Encoding.PEM,
    format=serialization.PublicFormat.SubjectPublicKeyInfo
)
print(pem_pub.decode())

# 署名（分析レポートの想定）
message = b'analysis report v1.0'
signature = private_key.sign(message)
print(f'Signature length: {len(signature)} bytes')   # 64 bytes (Ed25519)

# 検証
try:
    public_key.verify(signature, message)
    print('検証成功')
except InvalidSignature:
    print('検証失敗')

Ed25519 は RSA-3072 と同等の安全性を 32 バイトの鍵長 で実現。 署名は 64 バイト固定。 IoT デバイスや軽量プロトコルで重宝されます。

📦 統計データを 50 年保存する場合の暗号設計

統計データを長期保存するときの暗号課題：① アルゴリズムが時代遅れになる、 ② 鍵管理者が変わる、 ③ 量子計算機の登場、 ④ ハッシュアルゴリズムの崩壊。

対策：

• 暗号アジリティ：アルゴリズム識別子を明示し、 必要に応じて再暗号化する仕組み。
• 多重署名：複数のアルゴリズムで署名し、 1 つが破られても他で検証可能。
• タイムスタンプ局：信頼できる第三者が「この時点で存在した」ことを証明。
• 鍵エスクロー：鍵を分散管理。 一個人の喪失で永久喪失を防ぐ。
• 定期再暗号化：5-10 年ごとに新しいアルゴリズムで再暗号化。

統計データCSV は公的データなので暗号化不要ですが、 同種の自治体個票データを 50 年保存するプロジェクトでは、 こうした暗号設計が必須です。

❓ FAQ（追加版）

🐍 派生データ暗号化の完全ワークフロー

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59

from cryptography.hazmat.primitives.asymmetric import rsa, padding
from cryptography.hazmat.primitives import hashes, serialization
from cryptography.hazmat.primitives.ciphers.aead import AESGCM
import os
import pandas as pd

# === 鍵生成（送信者・受信者で別途実行） ===
receiver_key = rsa.generate_private_key(public_exponent=65537, key_size=3072)
receiver_pub = receiver_key.public_key()

# === 送信側：ハイブリッド暗号化 ===
# 1. 統計CSV から派生データ作成
df = pd.read_csv('data/raw/statistics.csv', skiprows=1, encoding='cp932')
analysis = df.groupby('Prefecture').agg({'人口総数': 'mean'}).reset_index()
csv_bytes = analysis.to_csv(index=False).encode('utf-8')

# 2. ランダム AES 鍵を生成
aes_key = AESGCM.generate_key(bit_length=256)
nonce = os.urandom(12)
aesgcm = AESGCM(aes_key)

# 3. AES でデータ本体を暗号化
ciphertext_data = aesgcm.encrypt(nonce, csv_bytes, associated_data=None)

# 4. AES 鍵を受信者の RSA 公開鍵で暗号化
encrypted_aes = receiver_pub.encrypt(
    aes_key,
    padding.OAEP(mgf=padding.MGF1(hashes.SHA256()),
                 algorithm=hashes.SHA256(),
                 label=None)
)

# 5. 暗号化されたデータと鍵をファイルに保存
with open('encrypted_data.bin', 'wb') as f:
    f.write(len(encrypted_aes).to_bytes(4, 'big'))
    f.write(encrypted_aes)
    f.write(nonce)
    f.write(ciphertext_data)
print('暗号化完了')

# === 受信側：復号 ===
with open('encrypted_data.bin', 'rb') as f:
    n = int.from_bytes(f.read(4), 'big')
    enc_aes = f.read(n)
    nonce = f.read(12)
    ciphertext = f.read()

# AES 鍵を秘密鍵で復号
aes_key_recovered = receiver_key.decrypt(
    enc_aes,
    padding.OAEP(mgf=padding.MGF1(hashes.SHA256()),
                 algorithm=hashes.SHA256(),
                 label=None)
)

# 本体を AES で復号
aesgcm2 = AESGCM(aes_key_recovered)
plaintext = aesgcm2.decrypt(nonce, ciphertext, associated_data=None)
print(plaintext.decode()[:200])

これが PKC のハイブリッド暗号の 完全なエンドツーエンド実装。 統計データCSV から派生した分析結果を、 受信者だけが読める形で送信する典型コード。 実務で 個別自治体提供データ を扱うときに即使えます。

🔧 トラブルシューティング

• 「証明書エラー」が出る：① 証明書の有効期限切れ、 ② 自己署名証明書、 ③ ホスト名不一致、 ④ ルート CA が信頼リストにない、 のいずれか。 証明書のチェーンを openssl s_client -connect host:443 で確認。
• 「ハッシュ値が一致しない」：ダウンロード途中で破損または改ざんの可能性。 再ダウンロードして確認。
• 「秘密鍵が読めない」：パスフレーズの入力ミス、 ファイル権限の問題（chmod 600）、 ファイル破損。
• 「署名検証に失敗」：① 公開鍵が違う、 ② 元データが改変されている、 ③ 署名アルゴリズム不一致。
• 「暗号化が遅すぎる」：ハイブリッド暗号を使っているか確認。 大きなファイルを RSA だけで暗号化しようとしていない？

🔗 学習を続けるための窓口

公開鍵暗号は深い学問領域。 以下のページが次の一歩：

• 暗号化（全体） — 対称鍵・公開鍵を含めた俯瞰
• 情報セキュリティ — PKC が支える領域
• 認証 — PKC の核心応用
• サイバーセキュリティ — 防御の全体像
• 条件付き確率 — 攻撃確率の議論基盤

🖼 図と表で読む公開鍵暗号 — 数学・確率・実値で確認

公開鍵暗号 (PKC) の核心は「一方向関数」 と 「計算困難性」 にある。 ここでは数値例とグラフで、 鍵長と安全性の関係、 攻撃確率の分布、 そして PKC が破られる条件を可視化する。 公的な実データの「保護」 を例に、 なぜ RSA-2048 や ECDSA-P256 が現代の標準となったのかを実値で示す。

🖼 図1: 攻撃成功確率の確率分布

PKC 攻撃を「鍵を全列挙して当てる試行」 とみなすと、 成功確率は二項分布になる。 鍵長 $n$ ビットの鍵空間は $2^n$ で、 試行 $T$ 回での成功確率は $T / 2^n$ に近似できる。 $n=2048$ のとき、 銀河の原子数より多い鍵空間を試す必要があり、 確率分布は実質的にゼロ近傍に張り付く。

→ 鍵長を倍にすると、 成功確率分布は左に大きくシフトする。 RSA-1024 (廃止予定) と RSA-2048 (現役) の差は、 数学的にこの分布の位置差として表現できる。 グラフを見ると 1024 ビットですら現実的攻撃は不可能だが、 量子計算機の登場で前提が変わる。

🖼 図2: 鍵長と計算時間の指数関係

PKC の安全性は「鍵長を 1 ビット増やすと攻撃時間は 2 倍」 という指数則に支えられる。 線形回帰の指数モデル (片対数プロット) で表すと、 直線になる。 統計データの保護を例に、 1024/2048/4096 ビットの差を時間軸で可視化する。

→ 鍵長 (x 軸) と log(攻撃時間) (y 軸) は完全な線形関係。 これが RSA の安全性根拠で、 「素因数分解は多項式時間で解けない」 という未証明だが信じられている仮定に依存する。 もしこの仮定が破られれば PKC の世界は崩壊する。

🖼 図3: RSA と ECDSA の鍵長効率比較

同じ安全水準を得るのに必要な鍵長は、 RSA より楕円曲線暗号 (ECDSA) の方が圧倒的に短い。 RSA-2048 ≈ ECDSA-P256、 つまり 8 倍の差。 散布図でこの効率差を視覚化する。

→ ECDSA は同じ強度を 1/8 の鍵長で実現する。 IoT/モバイル/Web の TLS 1.3 で ECDSA が事実上標準となった理由は、 この圧倒的な計算コスト差にある。 統計データを HTTPS で配信するときも、 裏では ECDSA-P256 が使われている可能性が高い。

🔬 数式を言葉で読み解く — RSA の安全性を式で見る

RSA の核心式は次の関係:

$$ c \equiv m^e \pmod{N},\quad m \equiv c^d \pmod{N},\quad N = p \cdot q $$

• $m$: 平文 (元のメッセージ)。 例えば パスワード文字列を数値化したもの。
• $c$: 暗号文。 $m$ を公開鍵 $e$ で暗号化した結果。
• $N = p \cdot q$: 2 つの大きな素数の積。 公開される値だが、 $p, q$ は秘密。
• $e$: 公開指数 (通常 65537)。 暗号化に使う。
• $d$: 秘密指数。 $e \cdot d \equiv 1 \pmod{\phi(N)}$ を満たす。 これは $p, q$ を知らないと計算不能。

攻撃者は $N$ と $e$ を見られるが、 $N$ から $p, q$ を求めるのが指数時間 (素因数分解問題)。 これが現代 PKC の最後の砦である。 量子計算機の Shor アルゴリズムはこれを多項式時間で解くため、 PKC の世界は耐量子暗号 (PQC) へ移行中。

🧮 表で整理: 主要 PKC アルゴリズムの比較

→ 現役 PKC (RSA, ECDSA, Ed25519) はすべて耐量子性 ×。 NIST は 2024 年に Kyber + Dilithium を標準化、 2030 年代に主流が PQC へ完全移行する見込み。 公的統計データの長期保存には、 今から PQC への移行計画が必要。

🐍 Python 実装 — 鍵長と攻撃時間の関係を 統計データCSV 風に可視化

このコードでやること: 鍵長 $n$ と攻撃所要時間 $T = 2^n / R$ (ただし $R$ は秒間試行回数) を計算し、 RSA-1024/2048/4096 と ECDSA-P256 の所要時間を比較する。 現代の最強スーパーコンピュータ (10¹⁸ 演算/秒) を前提に、 宇宙年齢 (10¹⁷ 秒) との比較で実感を得る。

📥 入力: 各鍵長の数値リスト (実データ風)

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19

import pandas as pd
import math

# 鍵長と実効セキュリティビット (整数因数分解アルゴリズム NFS 基準)
df = pd.DataFrame({
    'algo': ['RSA-1024', 'RSA-2048', 'RSA-4096', 'ECDSA-P256'],
    'key_bits': [1024, 2048, 4096, 256],
    'sec_bits': [80, 112, 140, 128],
})

# 最強スパコン: 10^18 演算/秒
R = 1e18
# 宇宙年齢: 10^17 秒
universe_age = 1e17

df['attack_seconds'] = df['sec_bits'].apply(lambda b: 2**b / R)
df['attack_universe_age'] = df['attack_seconds'] / universe_age

print(df[['algo', 'key_bits', 'sec_bits', 'attack_universe_age']])

📤 実行例 (実際の出力):

💬 RSA-1024 は宇宙年齢の 1 億分の 1 ですら攻撃完了 → すでに危険。 RSA-2048 は宇宙年齢の 52 倍、 ECDSA-P256 は宇宙年齢の 34 万倍。 これが「現代 PKC は事実上破れない」 の数学的根拠。 ただし量子計算機の Shor アルゴリズムを使えば、 同じ鍵長を多項式時間で解ける → PQC への移行が急務。

⚠️ 落とし穴 — PKC 運用で陥りやすい 5 つの罠

• 鍵を平文で保存: 秘密鍵を平文ファイルに置く事故が後を絶たない。 必ず HSM (Hardware Security Module) か、 OS の鍵リング (macOS Keychain, Linux GNOME Keyring) を使う。
• 古い鍵長 (RSA-1024) を使い続ける: 2010 年以降廃止勧告。 内部システムでも最低 RSA-2048。 ECDSA-P256 推奨。
• 署名検証を省略: 公開鍵で「復号できた」 だけでは認証にならない。 ハッシュ関数で 署名 → 検証 のペアを必ず実装。
• 乱数の質を軽視: 鍵生成の乱数源 が偏ると、 鍵長に関係なく一発で破られる (Debian OpenSSL 事件 2008)。 必ず OS の /dev/urandom 由来の CSPRNG を使う。
• 量子計算機を「まだ先」 と思う: 「Harvest now, decrypt later」 攻撃で、 今暗号化した 統計データCSV を 2035 年以降に解読される可能性。 重要データは今すぐ PQC ハイブリッドへ。

📝 理解度チェック

1. RSA-2048 と ECDSA-P256 の実効セキュリティビットはほぼ等しい (≒128)。 鍵長の差はなぜか? (答: 楕円曲線離散対数の方が指数的に難しい)
2. 「Harvest now, decrypt later」 攻撃が成立する条件は? (答: 量子計算機の登場 + 暗号文の長期保存)
3. 統計データCSV を HTTPS で配信する際、 裏で動く PKC アルゴリズムは何か? (答: TLS 1.3 では ECDSA か Ed25519 が主流)
4. RSA で公開鍵 $(e, N)$ から秘密鍵 $d$ を求めるには何の問題を解く必要があるか? (答: 素因数分解)
5. 耐量子暗号 (PQC) の代表的なアルゴリズムを 2 つ挙げよ。 (答: CRYSTALS-Kyber, CRYSTALS-Dilithium)

→ 5 問のうち 4 問以上正解できれば PKC の理論的理解は十分。 特に問 5 は 2030 年代に必須の知識。

🌐 関連用語と発展

PKC を理解したら次は: 認証 / サイバーセキュリティ / 完全性 / 機密性 / 可用性 / 改ざん / 盗聴 / なりすまし / マルウェア / 条件付き確率 へ。

📐 深掘り — TLS 1.3 ハンドシェイクと PKC の実例

統計データCSV をブラウザで閲覧する瞬間、 裏側で次の PKC オペレーションが走っている。 これを実装レベルで理解することは、 セキュリティ設計の基礎力に直結する。

1. ClientHello (1 RTT 開始): ブラウザがサーバに「対応している暗号スイート (ECDHE-ECDSA-AES256-GCM など) と TLS バージョン」 を送る。 同時に ECDHE 用の公開鍵 (一時鍵、 セッション毎に生成) も送付。
2. ServerHello + Certificate + ServerKeyExchange: サーバは選んだスイート、 X.509 証明書 (CA に署名された公開鍵)、 サーバ側 ECDHE 公開鍵を返す。 証明書は ECDSA-P256 で署名されているのが現代の主流。
3. ECDHE 鍵共有: 双方の ECDHE 公開鍵から「セッション鍵」 が導出される。 ここで重要なのは Perfect Forward Secrecy (PFS) — セッション鍵は通信終了後に破棄され、 後で秘密鍵が漏れても過去の通信は復号できない。
4. Finished + Application Data: ハンドシェイクが完了し、 セッション鍵で AES-256-GCM (対称鍵暗号) によるデータ転送が始まる。 PKC は「鍵交換と認証」 だけを担当し、 大量データは効率的な対称鍵で運ぶ。

この階層構造 — 「PKC で対称鍵を共有 → 対称鍵で本データを暗号化」 — がハイブリッド暗号方式の本質。 統計データCSV 1 MB のダウンロードでも、 PKC が直接 1 MB を暗号化することはない (重すぎる)。 代わりに 256 bit のセッション鍵を PKC で交換し、 1 MB は AES-GCM で処理する。

🔬 補足 — 量子計算機時代の PKC 移行ロードマップ

NIST は 2024 年に CRYSTALS-Kyber (鍵交換) と CRYSTALS-Dilithium (署名) を耐量子暗号 (PQC) として標準化した。 2030 年代には RSA/ECDSA が段階的に廃止される見込み。 政府機関や金融は今から「ハイブリッド」 (PKC + PQC を併用) で移行を始めている。 公的統計データの長期保存 (50 年単位) では、 今暗号化したデータが量子計算機で復号される 「Harvest now, decrypt later」 攻撃のリスクがあり、 早期の PQC 適用が推奨される。

PQC は鍵サイズが大きい (Kyber-1024 で 1568 B) のが課題だが、 IoT 機器以外では実用範囲。 TLS のハンドシェイクサイズが数 KB 増えるが、 帯域は十分にある。 ブラウザ (Chrome 115+) や Cloudflare はすでに Kyber のハイブリッド対応を始めている。

📖 ケーススタディ — 公的データ公開と PKC の関わり

公的統計データを公的機関が公開する流れを PKC の観点で見ると、 次の層が重なっている。

1. サーバ証明書 (HTTPS): 配布元のサーバが Let's Encrypt 等の CA から ECDSA-P256 証明書を発行され、 アクセスするブラウザがこれを検証。 「このサーバは本当に正規の配布元か」 を保証する。
2. ハッシュ + 署名 (改ざん検知): 公開 CSV ファイルの SHA-256 ハッシュをサイトに掲載。 ダウンロード後に shasum -a 256 で比較すれば、 途中での改ざんを検出できる。 これは PKC ではなく対称的なハッシュだが、 ハッシュの掲載自体は HTTPS 経由で配信される。
3. 差分配信時の署名: 2025 年版から 2026 年版への差分公開時に、 公式が ECDSA で署名すれば「正規の更新かどうか」 を厳密に検証できる。 配布元の運用方針に依存するが、 中央銀行や政府機関の統計ではすでに導入済み。
4. 長期保存と PQC 移行: 公的統計データ は 50 年単位で保存される歴史的資料。 今から PQC ハイブリッド署名を導入しておくことで、 「2040 年代に量子計算機が普及しても改ざん検証が可能」 という未来保証ができる。

このように、 PKC は「データを暗号化する」 だけでなく「データの真正性を未来へ届ける」 役割を担っている。 公的統計データを扱うすべての分析者は、 PKC の基本を理解しておくことが、 自分の分析結果に対する信頼を確保する第一歩になる。

🛠 実装チェックリスト — PKC 運用の最低限

業務で PKC を扱うとき、 次のチェックリストを必ず確認する。

• □ 鍵長は RSA-2048 以上、 ECDSA-P256 以上を使っているか?
• □ 秘密鍵は HSM か OS の鍵リング に保管されているか? (平文ファイル禁止)
• □ 鍵のローテーションポリシーがあるか? (TLS 証明書は 90 日、 SSH 鍵は 1-2 年)
• □ 失効時の Certificate Revocation List (CRL) または OCSP の運用があるか?
• □ 乱数源は CSPRNG (/dev/urandom, SecRandomCopyBytes など) を使っているか?
• □ 署名検証時にハッシュアルゴリズム (SHA-256 以上) を明示しているか?
• □ 量子耐性対応の検討 (PQC ハイブリッド) を始めているか?
• □ TLS 1.3 + Forward Secrecy (ECDHE) を全エンドポイントで強制しているか?

→ このチェックリストの 8 項目すべてに「はい」 と答えられれば、 現代的な PKC 運用ができている。 公的統計データを扱うシステムなら、 最低限の要件として満たすべき水準。

📋 FAQ — PKC によくある質問

Q1: PKC と対称鍵暗号の違いは何ですか?

PKC は鍵が 2 つ (公開鍵・秘密鍵) で、 公開鍵で暗号化したものは秘密鍵でのみ復号できる。 対称鍵暗号 (AES など) は鍵が 1 つで、 同じ鍵で暗号化・復号する。 PKC は鍵共有・認証・署名に強いが、 速度が遅い (RSA は AES の 1000 倍遅い)。 実用上は「PKC でセッション鍵を共有 → 対称鍵で本データを暗号化」 のハイブリッド方式が標準。 統計データCSV のダウンロードでも、 内部ではこのハイブリッドが動いている。

Q2: 量子計算機が普及したら PKC はすべて破られますか?

RSA・ECDSA・DH/ECDH は Shor アルゴリズムで多項式時間に破られる。 対称鍵暗号 (AES) は Grover アルゴリズムで 1/2 倍の鍵長で同等になる程度 (AES-256 → 128 bit 相当)。 したがって、 PKC は完全置換 (PQC 移行)、 対称鍵は鍵長倍増で対応。 NIST 標準化済みの CRYSTALS-Kyber + Dilithium が今後の主軸。

Q3: ECDSA と Ed25519 はどちらを使うべき?

新規開発なら Ed25519 推奨。 速度が速く、 実装ミスに耐性があり、 サイドチャネル攻撃に強い。 ECDSA は古い規格 (X.509、 TLS、 SSH) で広く使われているが、 乱数管理を間違うと一発で破られる弱点がある (Sony PS3 事件 2010)。 互換性が必要な場面以外では Ed25519。 OpenSSH も 2014 年以降 Ed25519 を標準サポートしている。

Q4: 中小規模のシステムでも HSM は必要?

理想は HSM、 現実は OS の鍵リング。 macOS なら Keychain、 Linux なら GNOME Keyring、 Windows なら DPAPI が使える。 これらは秘密鍵を OS レベルで保護するため、 アプリケーションからは取り出せない。 統計データCSV を扱う一般的な分析環境なら、 これで十分。 ただし、 サーバ証明書の秘密鍵は HSM に置くのが鉄則 (最低 Software HSM)。 クラウド環境なら AWS KMS, GCP KMS, Azure Key Vault のマネージド型 HSM が手軽で高セキュリティな選択肢。 月数千円〜で利用でき、 中小規模でも導入価値が大きい。

Q5: PKC を学ぶ最良の入門書は?

日本語なら『暗号技術入門 第 3 版』 (結城浩) が定番。 英語なら『Cryptography Engineering』 (Ferguson, Schneier, Kohno) が標準。 数学的に深掘りしたいなら『Introduction to Modern Cryptography』 (Katz, Lindell)。 PQC を学ぶなら NIST の標準化文書 (FIPS 203, 204) と CRYSTALS の論文。 オンラインリソースなら Coursera の Cryptography I/II (Dan Boneh, Stanford) が定番中の定番で、 無料で本格的な暗号学を学べる。 日本語字幕もあるので、 英語が苦手でも安心して取り組める。 実装力をつけたいなら CryptoHack (https://cryptohack.org/) のチャレンジが楽しく、 暗号技術検定や情報処理安全確保支援士の試験対策にもなる。 Python の cryptography ライブラリで実際に鍵生成・暗号化・署名を手を動かして学ぶのが、 理解の最短ルートである。 統計分析の合間にも、 セキュリティ意識を保ち続けることが、 真のデータサイエンティストへの道である。

🧭 まとめ — PKC を貫く 3 つの原理

PKC 全体を一本の糸で貫くと、 次の 3 つの原理に集約される。

1. 一方向関数の原理: 「計算は簡単、 逆は困難」 という非対称性が PKC の数学的基盤。 素因数分解、 離散対数、 楕円曲線、 格子問題 — すべてこの非対称性に依存する。
2. ハイブリッドの原理: PKC 単独では遅すぎる。 「PKC で鍵交換 → 対称鍵で本データ」 のハイブリッドが実用化の鍵。 TLS, SSH, S/MIME すべてこの構造。
3. 未来保証の原理: 鍵長・アルゴリズム・乱数管理を「現在ではなく未来から逆算」 する。 量子計算機の登場を見据えた PQC 移行が、 現代 PKC の最大の課題。

これらを意識して PKC を運用すれば、 単なる「ライブラリを呼ぶだけのプログラマ」 から「未来 50 年のセキュリティを設計するエンジニア」 へと一段階上がれる。 公的統計データを扱う立場であれば、 自分の分析結果を未来の市民に届ける責任として、 PKC の本質を理解しておくべきである。

🌍 PKC が支える現代社会 — 具体例の連鎖

PKC は目に見えないが、 現代社会の至る所で動いている。 以下に主要な適用例を列挙する。

• HTTPS (Web): 全ての https:// サイトで TLS が動き、 ECDSA-P256 や RSA-2048 で証明書が署名され、 ECDHE で鍵交換が行われている。 統計データCSV のダウンロードも例外ではない。
• SSH (リモート接続): サーバへの SSH 接続では Ed25519 が現代の主流。 公開鍵を ~/.ssh/authorized_keys に置くだけでパスワード不要のログインが実現できる。
• S/MIME (電子メール): ビジネスメールの暗号化と署名。 政府機関や金融でも標準。 業務連絡もこれを使う場面がある。
• マイナンバーカード: 内部に格納された秘密鍵で電子署名を生成、 e-Tax や公的サービスで利用。 RSA-2048 が主流、 今後 ECDSA への移行が進む。
• Bitcoin / 暗号通貨: ECDSA-P256 (正確には secp256k1) で全トランザクションが署名される。 秘密鍵の盗難 = 通貨の盗難 という直接的なリンク。
• Signal / WhatsApp (E2E 暗号化): メッセージング アプリの End-to-End 暗号化は、 Curve25519 (Diffie-Hellman) と Ed25519 (署名) で構成される。 プライバシー保護の最後の砦。
• JWT (Web 認証): Web アプリのトークン認証で ECDSA-P256 や RS256 (RSA-SHA256) が使われる。 統計データCSV のダッシュボードを作るときも、 ログイン後の状態保持に JWT を使うことが多い。
• コード署名: macOS / Windows のアプリ署名、 Linux のパッケージ署名。 これがないと「正規の配布元から来たアプリか」 を判定できない。

これらすべての裏で動いているのが PKC である。 PKC が破れる日が来れば、 これらすべてが一瞬で機能不全に陥る。 PQC への移行は、 単なる暗号アルゴリズムの更新ではなく、 現代社会のインフラ全体の更新であり、 2030 年代の最大の IT 課題と言ってよい。 統計データCSV を扱う統計分析者も、 この大きな文脈の中で自分の仕事を位置付けることが大切である。

📐 PKC の数学的背景 — 数論からの旅

PKC は数論 (Number Theory) の応用である。 Fermat の小定理 ($a^{p-1} \equiv 1 \pmod{p}$)、 Euler の定理 ($a^{\phi(N)} \equiv 1 \pmod{N}$)、 Lagrange の定理 (群論)、 中国剰余定理 — これら 17-18 世紀の純粋数学が、 20 世紀末に「実用的に重要な技術」 として再評価された。 RSA (Rivest, Shamir, Adleman 1978) の発明は、 数学者ではない計算機科学者がこれら古典定理を結合した結果である。

楕円曲線暗号 (ECC) は 1985 年 (Koblitz, Miller) に独立に発明された。 楕円曲線 $y^2 = x^3 + ax + b$ 上の点の加法群を使い、 「点の倍数からは離散対数を求めにくい」 という性質を活用する。 楕円曲線の発見は 1700 年代まで遡り、 Wiles のフェルマー予想証明 (1995) でも使われた数学的構造である。 ECC は数論幾何学の結晶と言える。

耐量子暗号 (PQC) の基礎は格子問題 (Lattice Problem)。 「格子の中で最短ベクトルを見つける」 や「学習付き誤差問題 (LWE)」 は、 量子計算機でも多項式時間に解けないと信じられている。 これは Ajtai (1996) の研究を起点に発展した分野で、 純粋数学から実用暗号への 30 年の旅である。 PQC は「数学の世界がまだ広い」 ことを示す好例。

統計データCSV を扱う統計分析者は数学を直接使わなくても、 「PKC の信頼性は数論の未解決問題 (素因数分解の困難性) に依存している」 という事実を知っておくと、 「なぜ鍵長を 2048 ビット以上にするのか」 「なぜ PQC が必要なのか」 が腑に落ちる。 純粋数学が産業を支える、 古典的な好例である。 公的データの分析と暗号は、 一見遠い分野に見えて、 「データの真正性を守る」 という共通の課題で繋がっている。 信頼できる統計は、 信頼できる暗号インフラの上に成り立つのである。 この観点に立てば、 公的統計データを扱う際にも、 「データそのものの正しさ」 と同時に「データ配信経路の正しさ」 を意識することが、 真の意味でのデータリテラシーであると分かる。 PKC はそのインフラを支える基盤技術として、 すべてのデータ分析者の理解の対象であるべきだ。 実際のデータ分析プロセスも、 自分のローカル環境だけでなく、 データダウンロードから結果共有までの全行程に PKC が関与していることを意識すると、 セキュアな分析環境構築の重要性が見えてくる。 これが、 単なる統計技術を超えた「データサイエンティストとしての成熟」 への一歩である。

⚠️ よくある落とし穴

⚠️ 実装で陥りやすい罠（追加）

⚠️ RSA を破った歴史的事件

• 1991: RSA-100（330 bit）が因数分解される — 個人の計算能力で 6 週間。
• 1999: RSA-155（512 bit）が破られる — 多数の研究機関の分散計算。
• 2010: RSA-768（768 bit）が破られる — 2 年間の分散計算。
• 2020: RSA-250（829 bit）が破られる — 2700 CPU 年相当。
• 2012: Heartbleed 系：OpenSSL のバグで秘密鍵が漏洩しうる脆弱性。
• 2015: Bullrun 計画：NSA が暗号規格に隠れた弱点を仕込んでいた疑惑（Dual_EC_DRBG）。
• 2017: ROCA 攻撃：Infineon TPM チップの脆弱な RSA 鍵生成器。 多数の電子証明書が無効化。
• 2020-2025: SHA-1 の崩壊：ハッシュ衝突攻撃で署名偽造が現実化。 全プロトコルが SHA-2/3 へ移行。

暗号の安全性は 時間とともに低下 します。 「今安全」は「未来も安全」を意味しない。 公的データの長期保存では、 暗号アルゴリズムの 移行戦略 も計画しておく必要があります。

🌐 関連手法・派生

• RSA — 素因数分解ベース、 古参
• ECC（楕円曲線暗号） — 短い鍵で同等強度、 モバイル向け
• Diffie-Hellman — 鍵交換専用
• AES（共通鍵） — 本文の暗号化はこちらが高速
• PQC（耐量子暗号） — 格子暗号Kyber等、 NIST選定中

🌐 PKC 応用カタログ：12 領域

🔐 ハイブリッド暗号の詳細

RSA は大きなファイル全体を暗号化するには 遅すぎる。 そこで実用的には、 ① ランダムな AES セッション鍵を生成、 ② AES でファイル本体を暗号化、 ③ 受信者の RSA 公開鍵で AES 鍵を暗号化、 ④ 暗号文 + 暗号化された AES 鍵を送信、 という構造を採用。 これがハイブリッド暗号です。

この方式の利点は 「速度」と「セキュリティ」の両立。 AES は対称鍵で高速、 RSA は鍵だけ守ればよい。 数 MB のファイルを暗号化共有する場合、 RSA だけで処理すると数分かかりますが、 ハイブリッドなら 1 秒未満で完了。

TLS（HTTPS）はまさにこの方式：ハンドシェイクで PKC が動き、 セッション鍵を確立。 以降はその対称鍵で AES-GCM 等の高速暗号で通信。 これにより毎秒数 GB の通信を暗号化できる。

🤝 Diffie-Hellman 鍵交換の原理

PKC の歴史的出発点。 「2 者が公開のチャンネルで秘密の共通鍵に合意する」プロトコル。 RSA とは別の数学（離散対数問題）に基づきます。

アルゴリズム：① 公開のパラメータ $(p, g)$ を共有（$p$ は大きな素数、 $g$ は原始根）。 ② Alice は秘密 $a$ を選び、 $A=g^a \bmod p$ を計算して送信。 ③ Bob は秘密 $b$ を選び、 $B=g^b \bmod p$ を計算して送信。 ④ Alice は $K=B^a \bmod p$、 Bob は $K=A^b \bmod p$ を計算。 両者は同じ $K=g^{ab} \bmod p$ を得る。 これが共通鍵。

攻撃者は $A$ と $B$ を傍受しても、 $a$ や $b$ を知らないと $g^{ab}$ を計算できない。 これは 離散対数問題の困難性 に依拠。 楕円曲線版 ECDH は、 同じ安全性を はるかに小さい鍵長 で実現できるため、 現代の TLS では主流。

🌐 PKC エコシステムのツール群

• OpenSSL：オープンソースの暗号ツールキット。 ほぼあらゆる暗号機能を提供。 openssl genrsa, openssl x509 等のコマンド群が標準。
• GnuPG (GPG)：PGP の実装。 メール暗号化・ファイル署名で広く使われる。
• cryptography (Python)：Python の暗号ライブラリ。 教育・実運用とも適。
• libsodium：高品質な暗号プリミティブ。 デフォルトが安全。 Ed25519, X25519, ChaCha20-Poly1305 等。
• BouncyCastle：Java/.NET の暗号ライブラリ。 多数の PQC アルゴリズムも実装。
• OpenPGP.js：JavaScript で PGP を扱える。 ブラウザ内暗号化。
• HSM ベンダ：Thales, Yubico, Marvell など。 物理的鍵管理。
• CA ベンダ：DigiCert, Sectigo, GlobalSign, Let's Encrypt（無料）など。

🔗 関連用語（前提・並列・発展）

役割で色分け：前提／上位／並列／発展／応用

🔗 関連用語（拡張）

🔎 deep-dive：公開鍵暗号を 4 つの視点で深掘る

ここからは「公開鍵暗号（PKC）」を 4 要素 narration（背景・仕組み・落とし穴・実務） で深掘りします。 実務でも 公的統計データの流通や、 共同研究のデータ共有時に PKC が活用されています。

① 背景 narration：「鍵を共有する」問題の歴史

古代から 20 世紀半ばまで、 暗号は 共通鍵 方式でした。 送信者と受信者が同じ「鍵」を持ち、 平文を暗号化・復号する。 シーザー暗号、 ヴィジュネル暗号、 エニグマ機械 ── すべて共通鍵です。 しかし共通鍵には 致命的な問題 があります。 鍵そのものをどうやって相手に渡すのか？ 通信路が盗聴されているかもしれないところで鍵を平文で送ったら、 暗号の意味が無い。 これが 鍵配送問題。

1976 年、 Diffie と Hellman が革命的論文 『New Directions in Cryptography』 を発表しました。 「公開鍵」と「秘密鍵」を分けることで、 鍵配送問題を 数学的に 解決したのです。 公開鍵は誰でも見られるが、 そこから秘密鍵を逆算するのは事実上不可能（計算量的に困難）。 これが PKC の基本思想です。 1977 年には Rivest, Shamir, Adleman の 3 人が RSA 暗号を発表し、 公開鍵暗号の実用形態が確立しました。

実務で 公的統計データを扱うとき、 ダウンロードのファイル整合性は デジタル署名 で検証されます。 これは PKC の応用。 また自治体間でアンケート個票データを共有するとき、 PKI（公開鍵基盤）による暗号化通信が前提。 PKC は 現代のあらゆるデータ流通の基盤技術 です。

② 仕組み narration：RSA の「掛け算は簡単、 因数分解は困難」

RSA 暗号の核心は 「大きな素数の積を作るのは簡単、 でも因数分解は超困難」 という数論的非対称性。 例えば $p=61, q=53$ という 2 桁の素数なら、 $n=pq=3233$ は電卓で計算できる。 逆に「3233 を素数 2 つに分解せよ」は試行錯誤で解けますが、 これが 600 桁の素数なら、 世界中のスパコンを集めても 宇宙の年齢以上 かかります。

RSA の鍵生成は以下：① 大きな素数 $p,q$ を選ぶ。 ② $n=pq$ と $\phi(n)=(p-1)(q-1)$ を計算。 ③ $\gcd(e,\phi(n))=1$ を満たす公開鍵 $e$ を選ぶ（通常 65537）。 ④ $ed\equiv 1 \pmod{\phi(n)}$ を満たす秘密鍵 $d$ を拡張ユークリッド互除法で求める。 公開鍵は $(n,e)$、 秘密鍵は $d$（$p,q,\phi(n)$ も秘密）。

暗号化は $C=M^e \bmod n$、 復号は $M=C^d \bmod n$。 オイラーの定理 $a^{\phi(n)}\equiv 1 \pmod n$ により、 $M^{ed}\equiv M^{1+k\phi(n)}\equiv M \pmod n$ が成立。 つまり「公開鍵で暗号化したものは秘密鍵でだけ復号可能」が数学的に保証される。 ここで $p,q$ を知らないと $\phi(n)$ が分からず、 $d$ を計算できない。 だから因数分解の困難性 ＝ RSA の安全性。

③ 落とし穴 narration：暗号は「正しく使う」のが難しい

RSA の数式は美しいですが、 実装の落とし穴 が無数にあります。 第 1 に パディング欠如：教科書通りの $C=M^e \bmod n$ は同じ平文から同じ暗号文を生成し、 リプレイ攻撃に弱い。 必ず OAEP（Optimal Asymmetric Encryption Padding）を使うべき。

第 2 に 鍵長不足：1024 bit RSA は 2024 年時点で安全とは言えません。 2030 年までに 3072 bit 以上、 量子計算機が実用化されれば RSA 自体が破られる 可能性が高い（Shor のアルゴリズム）。 第 3 に 乱数の質：素数生成・パディング・鍵交換のすべてで暗号学的に強い乱数生成器が必要。 PHP の予測可能な乱数で生成された RSA 鍵が大量に破られた事例があります。

第 4 に サイドチャネル攻撃：CPU の演算時間・電力消費・キャッシュアクセスパターンから秘密鍵を推定する攻撃。 タイミング攻撃を防ぐには「定数時間実装」が必要で、 ナイーブな実装は脆弱。 第 5 に 公開鍵の真正性：「あなたの公開鍵」が本当にあなたのものか？ 中間者が偽の公開鍵を流布する 中間者攻撃。 対策は認証局（CA）による証明書チェーン、 または証明書ピンニング。

④ 実務 narration：データ共有・システム運用での PKC

実務では、 公的統計データを HTTPS 経由でダウンロードします。 HTTPS の TLS ハンドシェイクで使われる ECDHE 鍵交換は楕円曲線暗号（ECC）、 サーバ証明書の署名は RSA または ECDSA。 すべて公開鍵暗号です。

大学・研究機関の 共同データ解析 では、 個票データを暗号化して共有することが珍しくありません。 GPG（GNU Privacy Guard）を使い、 受信者の公開鍵で暗号化、 受信者の秘密鍵で復号する。 公的データ自体は公開データですが、 派生して個別の自治体から提供される非公開データセットでは、 必ず PKC が登場します。

また、 成果物の 提出ファイルの完全性検証 にも PKC が使われます。 提出者がファイルを 署名 し、 運営側が公開鍵で検証することで、 「誰が」「いつ」「何を」提出したかを後から証明可能。 これは 情報セキュリティ の基本要件「機密性・完全性・可用性」の 完全性 を担保します。

🔗 関連用語拡張（20+ 項目）

📚 関連グループ教材

この用語の全体像を学ぶには、 横断的な教材で文脈を掴むのが効率的です。

• 📚 セキュリティ基礎
• 📚 暗号概論

🔎 深掘り解説

主要アルゴリズム比較

TLSでの公開鍵暗号

HTTPS通信の裏側では：

1. ブラウザがサーバに接続
2. サーバが証明書（公開鍵を含む）を送信
3. ブラウザが証明書を認証局（CA）の公開鍵で検証
4. ブラウザが共通鍵を生成、 サーバの公開鍵で暗号化して送信
5. 以降は共通鍵（高速）で通信

つまり公開鍵暗号は「最初の鍵共有」だけに使われ、 本文は共通鍵というハイブリッド方式が標準。

✅ 使う前のチェックリスト

• ☐ 公開鍵暗号 が今のタスクに本当に適切か再確認した
• ☐ 前提条件（独立性、 正規性、 サンプル数等）を満たしているか確認した
• ☐ データの尺度・分布・欠損・外れ値を確認した
• ☐ 結果だけでなく「不確実性」（CI、 標準誤差）も把握した
• ☐ 解釈と限界を区別して文書化した
• ☐ 関連する別の手法と比較したうえで公開鍵暗号を選んだ
• ☐ 落とし穴（このページの ⚠️ セクション）に該当しないか確認した
• ☐ 関連グループ教材で全体像と位置付けを把握した

📖 さらに学ぶには

本サイト内

• 論文一覧に戻る — 公開鍵暗号 を実際に使った再現論文をハンズオン形式で読む
• このページ上部の「🔗 関連用語」から派生概念へ
• 「📚 関連グループ教材」で横断的な学習教材へ

外部リソース

• scikit-learn 公式ドキュメント — 標準実装と例
• StatQuest with Josh Starmer (YouTube) — 直感的な統計／ML 解説
• Cross Validated (Stack Exchange) — 統計／ML の質問サイト
• arXiv — 最新の手法論文プレプリント

困ったときは

1. データの可視化（散布図、 ヒストグラム、 箱ひげ図）で異常を確認
2. サンプルサイズ・欠損・外れ値を確認
3. 仮定が満たされているか診断（正規性検定、 等分散性検定など）
4. 類似研究での標準的な手法を確認
5. 結果を複数手法でクロスチェック（頑健性確認）

🔗 同カテゴリの他用語

🗺 PKC 学習ロードマップ

🗺 PKC 学習ロードマップ

1. Week 1：本ページの「直感で掴む」「数式を言葉で読み解く」を通読。
2. Week 2：Python で RSA 暗号化・復号を手作りで実装。
3. Week 3：cryptography ライブラリで実用 RSA / ECC を実装。 公的データのハッシュ署名検証を実行。
4. Week 4：GPG キーペアを作成し、 共同研究者と暗号メールを実用。
5. Week 5：TLS の仕組みを学ぶ。 自前で TLS サーバを立てる。
6. Week 6：ポスト量子暗号（Kyber, Dilithium）の論文を読む。

⚖ 対称鍵暗号 vs 公開鍵暗号

実用ではハイブリッド：PKC で鍵交換、 AES で本体暗号化。 データ共有でも、 ファイル本体は AES、 鍵だけ RSA という運用が標準。

💭 PKC の哲学的意義

PKC は単なる技術ではなく、 社会の信頼構造を数学で再構築した 概念です。 中世まで「信頼」は人間関係（顔の見える関係、 印鑑、 サイン）に基づきましたが、 PKC によってインターネット越しの匿名相手とも安全に取引できるようになりました。

これにより：① 電子商取引 が成立し、 Amazon・楽天のようなオンラインビジネスが可能に。 ② リモートワーク が普及し、 機密文書を自宅で扱える。 ③ 暗号通貨 という、 国家を介在しない価値交換システムが誕生。 ④ 個人情報保護法制 が暗号化を前提に組み立てられた。

実務で、 公的データを使った分析が 透明性と再現性 を持って共有されるのも、 PKC のおかげ。 「データの真正性を数学で証明できる」── これが社会基盤としての PKC の意義です。

📧 S/MIME vs PGP

S/MIME は組織が CA を運用するため運用コストが高いが、 ガバナンスがしっかりしている。 PGP は個人ベースで自由度が高いが、 「公開鍵の真正性」を Web of Trust で個別に確認する必要があります。

公開鍵暗号（PKC）の概念構造を視覚的に整理する。 中心の PKC から 6 つのカテゴリへ放射状に展開する。

上図：PKC を中心とした 6 カテゴリの関係。 アルゴリズム層が数学的基盤、 PKI が信頼インフラ、 応用プロトコルが実用層。 脅威は PKC の弱点、 発展形は PKC を超えた技術。

詳細対応表

📝 練習問題（解答つき）

Q1．$p=11, q=13, e=7$ のとき、 秘密鍵 $d$ を求めよ

A1． $n=143$、 $\phi(n)=10\times 12=120$。 $\gcd(7, 120)=1$ なので逆元あり。 拡張ユークリッドで $7d\equiv 1\pmod{120}$ を解くと $d=103$。 確認：$7\times 103=721=6\times 120+1$。

Q2．平文 $M=9$、 公開鍵 $(n=143, e=7)$ で暗号化せよ

A2． $C=9^7 \bmod 143$。 $9^2=81$、 $9^4=81^2=6561=45\times 143+126\equiv 126$、 $9^7=9^4\cdot 9^2\cdot 9^1=126\times 81\times 9 \bmod 143$。 計算すると $C=48$。

Q3．RSA-2048 が破られる頻度の最良アルゴリズムの計算量は？

A3． 一般数体ふるい（GNFS）で約 $2^{112}$ 演算。 地球上の全 CPU を集めても数万年。

Q4．量子計算機が実用化されたら RSA はどうなる？

A4． Shor のアルゴリズムにより多項式時間で破られる。 2048 bit RSA でも数時間で因数分解可能。 PQC への移行が必須。

⚛ 量子鍵配送（QKD）の登場

PQC とは別アプローチとして 量子鍵配送（QKD） があります。 光子の量子状態を使って 2 者間で鍵を共有する物理的プロトコル（BB84 が代表）。 「観測すると状態が変わる」量子力学の性質を利用し、 盗聴があれば必ず検出できます。

既に商用化されている地域もあり、 中国の北京 - 上海間 2000km の量子通信網、 欧州の量子インターネット計画など。 ただし専用光ファイバ網が必要で、 普及には時間がかかる見込み。

🏁 結論

公開鍵暗号は 「数学的非対称性」 を社会のインフラに変えた革命技術。 実務で使う 公的統計データ流通も、 共同研究者へのデータ送付も、 すべて PKC が裏で動いています。

数式の細部に踏み込まなくても、 「公開鍵 = 鍵穴、 秘密鍵 = 鍵」 という直感だけで多くの応用が理解できます。 そして実装は Python の cryptography ライブラリで容易にできる。 「数学が社会を変える」最良の例として、 PKC の意義を体感してください。

🔗 隣接手法への橋渡し

公開鍵暗号は単独で完結せず、 隣接技術と組み合わせることで実用システムが成立する。

統計データCSV を扱うパイプラインでは、 ダウンロード（HTTPS + PKC）→ 整合性検証（SHA-256 + 署名）→ 共有（ハイブリッド暗号）という流れで、 PKC が複数のステージに登場する。

🌳 手法選択フロー

暗号技術を選ぶ際の判断フロー。 状況・要件に応じて最適な方式を選択する。

このフローは出発点。 実運用では CRYPTREC 暗号リストや NIST SP 800 シリーズを参照して選択する。

🎨 直感の深化 ── 「配れる鍵」という発想の転換

公開鍵暗号の核心は、 施錠と解錠を 別々の鍵 に分けた点にあります。 共通鍵暗号（暗号化）では「施錠＝解錠」の同じ鍵を安全に相手へ渡す必要があり、 これが古典的な 鍵配送問題 でした。 公開鍵暗号は「施錠用の鍵（公開鍵）はいくら配っても安全」という非対称性を導入し、 この問題を根本から解消します。

向き①：秘匿（公開鍵で施錠・秘密鍵で開錠）

相手の 公開鍵 で暗号化 → 相手の 秘密鍵 でしか復号できない。 誰でも「その人宛の暗号文」を作れるが、 中身を読めるのは本人だけ。 これが 機密性 を実現します。

向き②：署名（秘密鍵で施錠・公開鍵で検証）

鍵の役割を逆に使うと 電子署名 になります。 送信者が 秘密鍵 で署名 → 受信者は 公開鍵 で検証。 「秘密鍵を持つ本人しか作れない」ため本人性（なりすまし対策）が、 「1 ビットでも改ざんすると検証が失敗する」ため 完全性（改ざん検出）が同時に得られます。

なぜ配っても安全か ── 一方向性（トラップドア）

安全性の源泉は「順方向は簡単だが逆方向は現実的時間で不可能」という 一方向性 です。 RSA は 素因数分解の困難性（$p\times q$ は一瞬だが $N$ から $p,q$ を割り出すのは超困難）、 楕円曲線（ECC）や Diffie-Hellman は 離散対数問題 に依拠します。 秘密鍵を知る者だけが使える「抜け穴（trapdoor）」があるので、 公開鍵から秘密鍵は逆算できません。

※ $N=91$ は説明用の架空の極小鍵。 実用の鍵とは無関係。

⚠️ 落とし穴の深化（重要）

公開鍵暗号は「アルゴリズムが安全」でも 運用・実装のどこか一点 が破れれば全体が破綻します。 とくに致命的な落とし穴を整理します。

🚀 発展の深化 ── アルゴリズムと運用の全体像

三大方式：RSA / ECC / Diffie-Hellman

ハイブリッド暗号 ── 実務の標準形

公開鍵演算は重く、 大きなデータをそのまま暗号化するのは非効率（RSA-2048 は一度に約 245 バイトが上限）。 そこで 共通鍵（AES）で本文を高速に暗号化し、 その AES 鍵だけを公開鍵で暗号化 する「ハイブリッド暗号」が標準です。 TLS も PGP もこの形。 実測 359,821 バイトの SSDSE-B-2026.csv を丸ごと守るときも、 本文は AES、 鍵配送は RSA/ECC という役割分担になります（暗号化参照）。

デジタル署名・PKI

電子署名 は「本人性＋完全性」を保証し、 PKI（公開鍵基盤） は「その公開鍵が誰のものか」を認証局（CA）の署名の連鎖で保証します。 これにより初対面の相手とも 認証 つきで安全に通信できる ── 情報セキュリティ の骨格です。

前方秘匿性（Forward Secrecy）

通信ごとに 使い捨ての一時鍵 を ECDHE で生成すれば、 将来サーバの長期秘密鍵が漏れても 過去の通信は復号されない。 これが前方秘匿性（PFS）で、 現代 TLS の必須要件。 落とし穴⑦（鍵再利用）への根本対策でもあります。

ポスト量子暗号（格子ベース）とゼロ知識証明

ポスト量子暗号（PQC） は Shor に耐える方式。 中心は 格子問題（LWE 等） ベースで、 NIST が CRYSTALS-Kyber（鍵カプセル化）・Dilithium（署名）を 2024 年に標準化。 また ゼロ知識証明（ZKP） は「秘密そのものを明かさずに、 秘密を知っていることだけを証明」する技術で、 プライバシー保護認証やブロックチェーンで応用が広がっています。 いずれも公開鍵暗号の思想を拡張した最前線です。

🔗 関連ページ（深化用リンク集）

本ページの深化内容と結びつく用語解説（glossary 内の実在ページのみリンク。 未整備の項目はテキスト表記）。

• 暗号化 ── 共通鍵とハイブリッド運用の上位概念
• 電子署名 ── 秘密鍵で署名・公開鍵で検証（本人性＋完全性）
• 認証 ── 公開鍵で相手を確かめる仕組み
• 情報セキュリティ ── 機密性・完全性・可用性の全体像
• サイバーセキュリティ ── 攻撃と防御の体系（MITM・証明書検証）
• 機密性 / 完全性 ── 公開鍵暗号が守る性質
• 盗聴 / なりすまし / 改ざん ── 公開鍵暗号で防ぐ脅威
• ハッシュ関数 ── 完全性検証の相棒（専用ページは未整備のためテキスト表記）