🔖 キーワード索引

このページで扱う主要キーワード（クリックで該当セクションへ）：

🎨 直感で掴む

暗号化はデータを 意味不明な形（暗号文）に変換し、 鍵（key） を持つ者だけが復号できるようにする技術。 データサイエンスでは個人情報を扱う場面が頻発するため、 暗号化と関連概念（ハッシュ、 匿名化、 差分プライバシー）は必修です。

大別すると 2 方式：

• 共通鍵暗号（対称鍵）：暗号化と復号で 同じ鍵 を使う。 AES が代表。 高速で大容量データ向き。
• 公開鍵暗号（非対称鍵）：「公開鍵で暗号化、 秘密鍵で復号」。 RSA・ECC が代表。 鍵交換と電子署名向き。

実運用では ハイブリッド方式が主流。 公開鍵で「セッション鍵（共通鍵）」を安全に渡し、 大容量データはセッション鍵（AES）で暗号化します。 HTTPS / TLS はまさにこの構成。

🎮 手を動かして掴む：暗号の仕組み

教育目的で「鍵で読めなくして、 正しい鍵で戻す」という暗号の核心を体感します。 (a) シーザー暗号のシフト量スライダー、 (b) 共通鍵 vs 公開鍵の概念図と鍵配送問題、 (c) 頻度分析で古典暗号が破られる様子、 の 3 本立てです。

⚠️ 教材用の簡易暗号です。 ここで使うシーザー暗号・単純換字は学習専用のおもちゃであり、 実データの保護には絶対に使えません。 実運用は AES / RSA など標準アルゴリズムを使ってください。

(a) シーザー暗号：鍵（シフト量）で平文→暗号文

アルファベットを鍵の数だけ「ずらす」だけの最も単純な暗号（英字 A–Z のみ変換、 その他の文字はそのまま）。 スライダーを動かすと暗号文がリアルタイムに変わります。

👉 正しい鍵（＝暗号化に使ったシフト量）だけが元の文を復元します。 鍵が 1 つずれるだけで意味不明。 これが「鍵を持つ者だけが復号できる」の最小モデルです。

(b) 共通鍵 vs 公開鍵：仕組みと鍵配送問題

ボタンで 2 方式を切り替えます。 共通鍵は「同じ鍵で暗号化・復号」、 公開鍵は「公開鍵で暗号化・秘密鍵で復号」。 決定的な違いは鍵をどう相手に渡すかです。

(c) 頻度分析：なぜ単純換字（古典暗号）は弱いのか

シーザー暗号や単純換字は、 文字の「出現頻度の癖」がそのまま残ります。 英語で最も多い文字は E。 暗号文の中で一番多い文字は、 元の E が化けたものと推測でき、 鍵がバレます。 下の棒グラフは暗号文の文字頻度です。

👉 鍵の候補はたった 26 通り。 頻度の癖を使えば総当たりすら要りません。 「鍵空間が小さい」「平文の統計的性質が漏れる」——これが古典暗号の致命的な弱点です。 現代暗号（AES・RSA）は鍵空間が天文学的（$2^{256}$ など）で、 暗号文が統計的にランダム列と区別できないよう設計されています。

📐 数式・定義

共通鍵暗号は概念的に：

公開鍵暗号（RSA の簡略）：

📐 補足: 暗号化のオーダ・実数感覚

• AES-256 の鍵空間 = $2^{256} \approx 1.16 \times 10^{77}$。 宇宙の原子数（≒$10^{80}$）に匹敵。
• RSA-2048 の素因数分解は古典計算機で $2^{112}$ 演算相当（NIST 推計）。 量子計算機の Shor アルゴリズムでは多項式時間（破られる）。
• SHA-256 の出力空間 = $2^{256}$。 誕生日パラドックスで衝突に必要な試行は $2^{128}$ 回。
• bcrypt cost=12 = 1 回の検証に約 0.3 秒。 攻撃者が 10⁸ パスワードを試すと $10^8 \times 0.3 = 3 \times 10^7$ 秒 ≈ 約 1 年。
• SSDSE-B-2026 (359,821 byte) を AES で暗号化 = 約 1 ms（最近の CPU）。 RSA で全部暗号化すると約 60 秒（6 万倍遅い）。
• SSDSE 12 年分 (≒ 4.3 MB) を SHA-256 でハッシュ = 約 12 ms。 改ざん検知のコストは無視できる。

🔮 ポスト量子暗号 (PQC) と SSDSE 長期保管戦略

NIST は 2024 年 8 月に FIPS 203 (ML-KEM)、 FIPS 204 (ML-DSA)、 FIPS 205 (SLH-DSA) を正式公開。 既存暗号との対比は以下。

「いま暗号化したデータがいつまで安全か」マトリクス

SSDSE 教材を「2070 年まで安全」に配布する設計例

1. 本体 CSV (359,821 byte) を AES-256-GCM で暗号化
2. AES 鍵を ML-KEM-768 で配送（量子耐性鍵交換）
3. 電子署名は ML-DSA-65 で付与（量子耐性署名）
4. ファイル指紋は SHA-3-512 を併記
5. 鍵階層は HSM + 5/9 しきい値署名で管理

これで「量子計算機が 2040 年に実用化された」シナリオでも、 2070 年時点で読めて、 かつ改ざん検出可能。 国の公的統計データの理想形。

❓ FAQ（追加）

📘 用語日英対応表（30 件）

🧱 暗号化を支えるプロトコルスタック

「暗号化」は単体で動くものではなく、 OSI 階層の各層に薬味のように埋め込まれている。 SSDSE データが研究者の手元に届くまでに走る全プロトコルを整理する。

⚖️ 暗号化と法令（日本・GDPR・米国）

🔬 数式を言葉で読み解く

🔬 数式を言葉で読み解く（深掘り）

このセクションでは「数式を言葉で読み解く」観点を、 共通鍵・公開鍵・ハッシュの 3 種類に分けて改めて整理する。 単なる記号の説明ではなく、 「なぜそのような数式が安全性を保証するのか」に踏み込む。

共通鍵 $C = E_K(M)$ を言葉で読み解く

• $M$（平文）= 暗号化したい元データ。 例: SSDSE-B-2026 のバイト列 359,821 個。
• $K$（鍵）= AES なら 128/192/256 ビットのランダムビット列。 これだけは絶対漏洩させてはいけない。
• $E_K$（暗号化関数）= 鍵 $K$ をパラメータとしてもつ関数族。 $K$ が違えば $E_K$ も別物。
• $C$（暗号文）= 統計的にランダム列と区別がつかないバイト列。 これが暗号の安全性の根拠（IND-CPA）。
• 復号は $M = D_K(C)$ で、 同じ鍵 $K$ を使う。 鍵が共通だから「共通鍵暗号」と呼ぶ。

「同じ鍵で暗号化と復号」── これが共通鍵の本質。 利点は高速（AES-NI 命令で 1 GB/秒級）、 欠点は鍵を相手に安全に渡す方法が別途必要。 その解決策が次の公開鍵暗号。

公開鍵（RSA）$C = M^e \bmod n$ を言葉で読み解く

• $n = pq$（2 つの大きな素数の積）= 公開してよい合成数（2048 ビット以上）。
• $e$ = 公開指数。 通常は $e = 65537$。
• $d$ = 秘密指数。 $ed \equiv 1 \pmod{\varphi(n)}$ を満たす唯一の値。 これだけは秘匿。
• $(e, n)$ から $d$ を計算するには $n$ を $p$ と $q$ に素因数分解する必要があるが、 これが「困難問題」。
• 送信者は公開鍵 $(e, n)$ だけ知っていれば $C = M^e \bmod n$ で暗号化できる。 受信者だけが秘密鍵 $d$ で $M = C^d \bmod n$ と復号できる。

「公開してよい鍵で暗号化、 秘密の鍵で復号」── これが公開鍵の本質。 鍵交換問題を解決できる代わりに、 共通鍵の 100〜1000 倍遅い。 だから現実はハイブリッド（公開鍵で AES 鍵を交換 → 本体は AES）。

ハッシュ $H: \{0,1\}^* \to \{0,1\}^n$ を言葉で読み解く

• 入力 = 任意長のバイト列（SSDSE CSV 359,821 byte でも、 短い「abc」3 byte でも OK）。
• 出力 = 固定長（SHA-256 なら 256 ビット = 32 byte）。 「指紋」と呼ばれる。
• 一方向性: ハッシュ値 $H(x)$ から元の $x$ を計算するのは困難。
• 衝突困難: $H(x) = H(y)$ となる $x \neq y$ を見つけるのは困難。
• 雪崩効果: 入力を 1 ビット変えるとハッシュは半分のビットがランダムに反転する。

「短く・一方向・衝突しない」── これが暗号学的ハッシュの本質。 暗号化ではないが、 改ざん検知・パスワード保管・電子署名の中核として暗号と必ずセットで使う。

BCRYPT のコスト要素を言葉で読み解く

bcrypt のハッシュ文字列 $2b$12$KxYz... の各部の意味:

コストを 12 から 13 に上げると計算時間が 2 倍に。 攻撃者の総当たり時間も 2 倍になる。 ハードウェア進歩に合わせて毎年 1 上げるのが推奨。

🛤 SSDSE-B-2026 を使った「暗号化の運用フロー」フルウォークスルー

ここまでの 5 個の Python 実装を組み合わせて、 「個人住民データを SSDSE 集計形式に整理 → 暗号化保管 → 配布」までの 7 段階を物語仕立てで追体験する。

SSDSE-B-2026 が e-Stat から配布される時点で既に段階 5 までは終わっている（個人データは 564 行に集約済み）。 教材として「再現せよ」と言われたとき、 学生は段階 1〜5 を裏で支える暗号技術を理解しておく必要がある。

段階 4: 個人 ID → 県別集計のハッシュ化（疑似コード）

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

import hashlib, pandas as pd

# 仮の個人レベル住民データ（実際は数千万行）
individuals = pd.DataFrame({
    'person_id': [f'P{i:07d}' for i in range(100)],
    '都道府県': ['東京都']*50 + ['大阪府']*30 + ['鳥取県']*20,
})
# 個人 ID をハッシュ化（一方向、 復元不能）
individuals['hash_id'] = individuals['person_id'].apply(
    lambda x: hashlib.sha256(x.encode()).hexdigest()[:16])

# 集計（SSDSE-B-2026 形式）
agg = individuals.groupby('都道府県').size().rename('count')
print(agg)

📤 実行例:

💬 個人 ID は hash_id 列にハッシュ化済みなので元の person_id を削除すれば、 「都道府県別人数」という SSDSE 互換の形式が残る。 ここから先は段階 5 以降。

📰 暗号化の現場ケーススタディ 6 件

ケース A: 国勢調査オンライン回答の暗号化

2020 年国勢調査オンライン回答では、 ブラウザ → 総務省サーバ間を TLS 1.2 以上（AES-GCM）で暗号化。 サーバ保管時も AES-256 で再暗号化。 鍵は HSM（ハードウェアセキュリティモジュール）に保管。 SSDSE-B-2026 のような集計値はこの巨大な暗号化基盤の最終成果物。

ケース B: マイナンバーカード IC チップ

IC チップ内に RSA-2048 秘密鍵が格納され、 チップ外には絶対出ない構造（HSM 化）。 e-Tax の電子署名はこの秘密鍵で行われ、 役所が公開鍵で検証。 これがあれば「本人が出した」を暗号で証明できる。

ケース C: HTTPS 普及率（2024 年）

Chrome 上の Web トラフィックは 95% 以上が HTTPS。 TLS 1.3 が主流で、 ChaCha20-Poly1305 が iPhone 系で多用される。 SSDSE データを e-Stat からダウンロードするときも自動的に AES/ChaCha20 で暗号化されている。

ケース D: 連合学習（Federated Learning）と暗号

医療データを病院間で共有せず、 各病院でモデルを学習し勾配だけを暗号化して送信。 サーバが勾配を集約して全体モデルを更新。 SSDSE の県別集計値もこの考え方の遠縁: 個人データではなく集計値だけ共有する。

ケース E: ブロックチェーンとハッシュチェーン

ビットコインのブロックは「前ブロックの SHA-256 ハッシュ」を含む。 1 ブロック改ざんすると以後すべてのハッシュが不整合になり、 ネットワーク全体で拒否される。 SSDSE データの「過去 12 年分（2012〜2023）」もハッシュチェーン化すれば改ざん耐性を確保できる。

ケース F: 量子計算機と SSDSE の長期保管

SSDSE は 2012 年から毎年更新。 50 年後の研究者がアクセスする可能性を考えると、 量子計算機で破られる RSA-2048 ではなく ML-KEM / ML-DSA のような PQC アルゴリズムで暗号化・署名しておく必要がある（NIST が 2024 年に標準化）。

🚫 暗号化アンチパターン集

📊 主要暗号ライブラリの比較

🔧 AES の内部構造を直感で掴む

AES（Advanced Encryption Standard）は 128/192/256 ビット鍵の共通鍵ブロック暗号で、 1 ブロックは 128 ビット（16 byte）固定。 SSDSE-B-2026 (359,821 byte) を AES で暗号化すると、 内部では 22,489 ブロック分の演算が走る計算。 1 ブロックは「4×4 = 16 byte の状態」を 10〜14 ラウンド処理する。

1 ラウンドは SubBytes → ShiftRows → MixColumns → AddRoundKey の 4 段階。 これは「散る・回す・混ぜる・鍵を足す」を交互に繰り返すことで、 入力 1 ビットの変化が出力すべてのビットに統計的に影響する（雪崩効果）。

AES の動作モード（運用上の最重要選択）

Fernet が AES-128-CBC + HMAC-SHA256 である理由

Fernet は「初心者でも安全に使える AEAD」として 2014 年に Heroku が公開した仕様。 AES-128-CBC で暗号化、 HMAC-SHA256 で改ざん検知、 タイムスタンプで再送攻撃も部分的に対策。 鍵は 32 byte（前半 16 byte が暗号化用、 後半 16 byte が HMAC 用）の base64 文字列。

「とにかく素早く対称暗号を使いたい」場合は Fernet。 「最高速・最新仕様」なら AES-GCM や ChaCha20-Poly1305 を直接使う、 という使い分け。

🧮 実値で計算してみる（SSDSE-B-2026）

🧮 SSDSE-B-2026 実値で確かめる暗号化の効果

ここからは SSDSE-B-2026 実 CSV (359,821 byte, 564 行 × 112 列) を題材に、 暗号化前後のバイト数・ハッシュ値・処理時間を 実値で確かめます。 47 都道府県の人口・婚姻・離婚など実列名を使うので、 教材として再現可能です。

暗号化前 CSV の素性（実測値）

2023 年度 47 県の総人口（要点抜粋）

これらは暗号化対象「平文 CSV」の中身。 暗号化後の暗号文はバイト列としては意味不明になり、 鍵がないと元の数値は復元できない、 という事実を以下で実コードで示します。

🧮 数式に値を入れて手で計算する: シーザー暗号と XOR 暗号

合成データで簡単な暗号化・復号化を計算する。

Step 1: シーザー暗号 (シフト 3)

Step 2: XOR 暗号 (鍵 0x5A)

🐍 Python で再現

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

def caesar(s, shift):
    return ''.join(chr(((ord(c) - 65 + shift) % 26) + 65) for c in s)
def xor_enc(s, key):
    return bytes(c ^ key for c in s.encode())

msg = "HELLO"
print(f"Caesar(3): {caesar(msg, 3)}")
enc = xor_enc(msg, 0x5A)
dec = xor_enc(enc.decode('latin1'), 0x5A).decode()
print(f"XOR 暗号 hex: {enc.hex()}")
print(f"XOR 復号: {dec}")

📤 実行結果

💬 手計算 (Step 1) "KHOOR" と Python 出力が完全一致。 復号で元に戻る。

🐍 Python 実装

例 1：Fernet（対称暗号、 すぐ使える AES ベース）

1
2
3
4
5
6
7
8

from cryptography.fernet import Fernet

key = Fernet.generate_key()
f = Fernet(key)
plaintext = b'patient_id=12345 | bp=130/85'
token = f.encrypt(plaintext)
print('暗号文:', token)
print('復号:', f.decrypt(token))

例 2：SSDSE データの列を Fernet で暗号化保管（個人情報結合想定）

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

import pandas as pd
from cryptography.fernet import Fernet

df = pd.read_csv('data/raw/SSDSE-B-2026.csv', encoding='shift_jis')
df.columns = df.iloc[0]
df = df.iloc[1:].reset_index(drop=True)

key = Fernet.generate_key()
f = Fernet(key)
# 仮の「個人ID」列を追加して暗号化（モデル用）
df['encrypted_id'] = df['地域コード'].apply(lambda s: f.encrypt(str(s).encode()).decode())
print(df[['都道府県','encrypted_id']].head())

例 3：SHA-256 ハッシュでデータ改ざん検知

1
2
3
4
5
6

import hashlib

with open('data/raw/SSDSE-B-2026.csv', 'rb') as fp:
    digest = hashlib.sha256(fp.read()).hexdigest()
print('CSV の SHA-256:', digest)
# このダイジェストを別途記録しておけば、 ファイルが書き換えられたら検出できる

例 4：RSA で電子署名（送信元証明）

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

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

priv = rsa.generate_private_key(public_exponent=65537, key_size=2048)
pub = priv.public_key()

msg = 'SSDSE-B-2026 集計結果 2026-05-20'.encode('utf-8')   # b'' に日本語は入れられない
sig = priv.sign(
    msg,
    padding.PSS(mgf=padding.MGF1(hashes.SHA256()),
                salt_length=padding.PSS.MAX_LENGTH),
    hashes.SHA256())
print('署名長:', len(sig))

# 検証
pub.verify(sig, msg,
           padding.PSS(mgf=padding.MGF1(hashes.SHA256()),
                       salt_length=padding.PSS.MAX_LENGTH),
           hashes.SHA256())
print('検証 OK')

例 5：パスワードハッシュ（bcrypt）

1
2
3
4
5

import bcrypt
pw = b'mySecretP@ss123'
hashed = bcrypt.hashpw(pw, bcrypt.gensalt(rounds=12))
print(hashed)
print('一致?:', bcrypt.checkpw(pw, hashed))

📂 ケーススタディ・追加実装例

ケース 1：HTTPS の中身（ハイブリッド暗号）

1. クライアントがサーバの証明書（公開鍵）を取得
2. クライアントが乱数からセッション鍵を生成 → サーバの公開鍵で暗号化して送信
3. 以後の通信はセッション鍵（AES）で暗号化、 高速通信
4. TLS 1.3 では Diffie-Hellman 鍵交換で前方秘匿性も確保

ケース 2：パスワード保管のレイヤー

ケース 3：個人情報結合データの暗号化保管

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

import os
os.makedirs('processed', exist_ok=True)   # 書き出し先を先に作る
import pandas as pd
from cryptography.fernet import Fernet

# 1) マスター鍵を環境変数から（コード／DB には書かない）
import os
# 本番では環境変数から読む: key = os.environ['DATA_KEY'].encode()
# ここでは動かせるように、無ければその場で作る
key = os.environ.get('DATA_KEY', Fernet.generate_key().decode()).encode()
f = Fernet(key)

df = pd.read_csv('data/raw/SSDSE-B-2026.csv', encoding='shift_jis')
df.columns = df.iloc[0]
df = df.iloc[1:].reset_index(drop=True)

# 2) 識別子列を暗号化して保存
df['ID_enc'] = df['地域コード'].apply(lambda s: f.encrypt(str(s).encode()).decode())
df.drop(columns=['地域コード']).to_parquet('processed/secured.parquet')

ケース 4：JWT（JSON Web Token）の構造

「ヘッダ.ペイロード.署名」の 3 つを base64 で連結。 署名は HMAC-SHA256 または RSA。 認証 API で頻出。

ケース 5：差分プライバシー（暗号化との補完）

1
2
3
4
5
6
7

import numpy as np
def dp_count(true_count, eps=1.0):
    # Laplace ノイズで count をぼかす（教育用、 実運用は専用ライブラリ）
    return true_count + np.random.default_rng().laplace(0, 1/eps)

# 例: 「東京都の高齢者数」を ε=1 でぼかす
print(dp_count(3_758_000, eps=1.0))

ケース 6：ポスト量子暗号（PQC）

2024 年に NIST が標準化した次世代アルゴリズム：

• ML-KEM（旧 Kyber）— 鍵カプセル化
• ML-DSA（旧 Dilithium）— 電子署名
• SLH-DSA（旧 SPHINCS+）— ハッシュベース署名

RSA・ECC は量子計算機の Shor アルゴリズムで破られるため、 中長期で PQC への移行が進む。

🪜 ステップバイステップ チュートリアル

チュートリアル：個人情報結合データの安全な扱い

ステップ 1：脅威モデルを決める

• 誰から守るか：内部不正・外部攻撃・誤送信
• 何を守るか：氏名・住所・生年月日・電話番号
• どこまで使う：分析者は集計のみ閲覧可

ステップ 2：鍵を作って環境変数へ

1
2
3
4
5

from cryptography.fernet import Fernet
key = Fernet.generate_key()
# .env に書き込む（リポジトリには絶対にコミットしない）
with open('.env', 'w') as f:
    f.write(f'DATA_KEY={key.decode()}\n')

ステップ 3：列暗号化

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

import os
os.makedirs('processed', exist_ok=True)   # 書き出し先を先に作る
import os, pandas as pd
from dotenv import load_dotenv
from cryptography.fernet import Fernet

load_dotenv()
f = Fernet(os.environ['DATA_KEY'].encode())

df = pd.read_csv('data/raw/SSDSE-B-2026.csv', encoding='shift_jis')
df.columns = df.iloc[0]
df = df.iloc[1:].reset_index(drop=True)
# 仮の個人 ID 列を生成（実運用では実 ID）
df['person_id'] = 'P' + (df.index+1).astype(str).str.zfill(5)
df['person_id_enc'] = df['person_id'].apply(lambda s: f.encrypt(s.encode()).decode())
df.drop(columns=['person_id']).to_parquet('processed/secured.parquet')

ステップ 4：ハッシュ化（一方向）

1
2
3
4
5

import hashlib
def hsh(s, salt='SSDSE_2026'):
    return hashlib.sha256((salt+s).encode()).hexdigest()
df['person_id_hash'] = df['person_id'].apply(hsh)
# DB の結合キーには hash を使う

ステップ 5：CSV のチェックサム

1
2
3
4

with open('data/raw/SSDSE-B-2026.csv','rb') as f_:
    digest = hashlib.sha256(f_.read()).hexdigest()
print('CSV SHA-256:', digest)
# このダイジェストを版管理に記録 → 改ざんを検知

ステップ 6：通信暗号化（TLS）

外部に送るときは HTTPS 必須。 Python の requests はデフォルトで TLS 検証を行う。 自前 API なら Let's Encrypt の証明書で TLS 1.3 を立てる。

🚀 現場での応用シナリオ（8 例）

応用 1：HTTPS / TLS

Web 通信の暗号化。 公開鍵で鍵交換 → 共通鍵で大容量データ。 ブラウザの鍵マークの背後。

応用 2：パスワード保管

bcrypt / Argon2 + 塩。 漏洩 DB でも個別パスワードを守る。 標準実装は passlib。

応用 3：データベース暗号化

Transparent Data Encryption (TDE)、 列暗号化、 Always Encrypted。 個人情報列を選択的に保護。

応用 4：電子署名と認証

JWT、 PDF 電子署名、 マイナンバーカード。 「本人が出した」を暗号で証明。

応用 5：ブロックチェーン

ハッシュチェーン + 公開鍵署名で改ざん不能な台帳。 暗号通貨・NFT・サプライチェーン追跡。

応用 6：連合学習 (Federated Learning)

「データは送らず、 モデル更新だけ送る」。 暗号化通信 + 差分プライバシーで医療・金融データの連携学習。

応用 7：同型暗号

「暗号化したまま計算する」最先端技術。 クラウドに復号鍵を渡さずに分析。

応用 8：マイナンバーカード

IC チップ内の秘密鍵で電子署名。 行政手続きのデジタル化の基盤技術。

🏋️ 演習問題（8 題）

1. Fernet で短いテキストを暗号化・復号せよ。
2. SSDSE-B-2026 の「地域コード」列を暗号化して別ファイルに保存せよ。
3. SHA-256 で「マイナンバー」風の文字列を 100 件ハッシュ化せよ。
4. bcrypt でパスワードを保存し、 認証ロジックを実装せよ。
5. RSA 鍵ペアを生成し、 短いメッセージに電子署名を付けよ。
6. TLS バージョンと暗号スイートを openssl s_client で確認せよ。
7. k-匿名化（K=5）を SSDSE 結合データに適用するスクリプトを書け。
8. 差分プライバシーで集計値にノイズを加え、 ε と精度のトレードオフを示せ。

🐍 SSDSE 実 CSV を AES-Fernet で暗号化（実値で検証）

🎯 このコードでやること: SSDSE-B-2026 の生 CSV を Fernet（AES-128-CBC + HMAC-SHA256）で 丸ごと暗号化し、 暗号化前後のバイト数差を実測する。

📥 入力データ（実測）:

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

from cryptography.fernet import Fernet
import os

# 1) 鍵生成（実運用は KMS に保管）
key = Fernet.generate_key()
f   = Fernet(key)

# 2) 平文 CSV を読み込む
with open('data/raw/SSDSE-B-2026.csv', 'rb') as fp:
    plain = fp.read()

# 3) 暗号化と出力比較
cipher = f.encrypt(plain)
print('平文 サイズ:', len(plain),  'byte')
print('暗号文 サイズ:', len(cipher), 'byte')
print('暗号文 先頭 60 文字:', cipher[:60])

# 4) 復号して中身が一致するか確認
restored = f.decrypt(cipher)
print('復号一致?:', restored == plain)

📤 実行例:

💬 結果の読み方: 暗号文は 359,821 → 479,796 byte に +33% 膨張（IV 16 byte + HMAC 32 byte + base64 化 4/3 倍）。 先頭 60 文字を見ると元の「年度,地域コード,都道府県...」の構造が完全に消滅。 復号後の一致確認 True で「鍵があれば 100% 戻せる」が実証された。

🐍 SHA-256 で改ざん検知（実 CSV のダイジェスト）

🎯 このコードでやること: SSDSE-B-2026 CSV の SHA-256 ダイジェストを計算し、 1 byte だけ書き換えた偽 CSV と比較して「ハッシュは雪崩効果で全く別の値になる」ことを示す。

📥 入力データ: SSDSE-B-2026.csv (359,821 byte)

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

import hashlib

# 1) 元 CSV のハッシュ
with open('data/raw/SSDSE-B-2026.csv', 'rb') as fp:
    orig = fp.read()
h_orig = hashlib.sha256(orig).hexdigest()

# 2) 1 byte だけ書き換え（北海道人口の「5092000」を「5092001」に偽装）
tampered = orig.replace(b'5092000', b'5092001', 1)
h_tamp = hashlib.sha256(tampered).hexdigest()

print('元 CSV  SHA-256:', h_orig)
print('改ざん SHA-256:', h_tamp)
print('一致?:', h_orig == h_tamp)

📤 実行例:

💬 結果の読み方: たった 1 byte 違いで 64 桁のハッシュ全体が変わる（雪崩効果）。 つまり SSDSE データ配布時にハッシュを併記しておけば、 受領側で sha256sum し、 同じ値か照合するだけで改ざん検知ができる。 e-Stat や政府機関の CSV 配布ページがチェックサムを併記する根拠。

🐍 都道府県名列だけを Fernet で列暗号化（プライバシー保護）

🎯 このコードでやること: SSDSE-B-2026 を pandas で読み、 都道府県列だけを Fernet で個別暗号化して保存。 集計値（人口・婚姻数）は平文のまま、 識別子だけを保護する「列レベル暗号化」を実演。

📥 入力データ: pd.read_csv('data/raw/SSDSE-B-2026.csv', encoding='cp932', skiprows=2, header=None) の最初の 3 行（カラム名は 2 行目から取得）:

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

import pandas as pd
from cryptography.fernet import Fernet

# 1) ヘッダ行を 2 行目（日本語）から取得して読み込む
hdr = pd.read_csv('data/raw/SSDSE-B-2026.csv', encoding='cp932',
                  nrows=2, header=None).iloc[1].tolist()
df  = pd.read_csv('data/raw/SSDSE-B-2026.csv', encoding='cp932',
                  skiprows=2, header=None, names=hdr)
df = df[df['年度'] == 2023][['都道府県', '総人口', '婚姻件数']].copy()

# 2) 鍵を生成し、 都道府県名だけ暗号化
key = Fernet.generate_key()
fer = Fernet(key)
df['都道府県_enc'] = df['都道府県'].apply(
    lambda s: fer.encrypt(s.encode('utf-8')).decode())
df = df.drop(columns=['都道府県'])

print(df.head(3))
print('暗号化列の長さ:', df['都道府県_enc'].iloc[0].__len__())

📤 実行例:

💬 結果の読み方: 暗号化された「北海道」「青森県」「岩手県」は元の 3 文字（UTF-8 で 9 byte）から base64 で 100 文字に膨張（Fernet トークン = バージョン 1 + タイムスタンプ 8 + IV 16 + 本文 16 + HMAC 32 = 73 byte を base64 化）。 なお行番号が 0, 12, 24 と飛んでいるのは、 1 都道府県あたり複数年度の行があり 2023 年度だけを抜き出したため。 gAAAAABq... の文字列そのものは暗号化した時刻とランダム IV を含むので 1 回ごとに別の値になる（長さ 100 文字は一定）。 つまり同じ「北海道」を 2 回暗号化しても毎回違う暗号文になる（Fernet は IV ランダム化）。 これがプライバシー保護の鍵で、 暗号文を見ても「東京都の方が多い」などの統計的推測ができない。

🐍 RSA 公開鍵で電子署名（SSDSE 集計表に署名）

🎯 このコードでやること: 「2023 年度 47 県の総人口合計 = 124,353,000 人」という SSDSE 集計値に RSA-2048 + SHA-256 で電子署名を付与。 受信者は公開鍵で検証することで、 集計値が改ざんされていないと確信できる。

📥 入力データ: 平文メッセージ b"SSDSE-B-2026 / 2023 / total_population = 124353000"

 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

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

# 2) SSDSE 集計値の宣言文に署名
msg = b"SSDSE-B-2026 / 2023 / total_population = 124353000"
sig = priv.sign(msg,
    padding.PSS(mgf=padding.MGF1(hashes.SHA256()),
                salt_length=padding.PSS.MAX_LENGTH),
    hashes.SHA256())
print('署名長:', len(sig), 'byte')

# 3) 検証（公開鍵側）
try:
    pub.verify(sig, msg,
        padding.PSS(mgf=padding.MGF1(hashes.SHA256()),
                    salt_length=padding.PSS.MAX_LENGTH),
        hashes.SHA256())
    print('検証 OK: 本人作成 & 改ざんなし')
except Exception:
    print('検証 NG')

# 4) 改ざんメッセージで再検証 → 必ず失敗
bad_msg = msg.replace(b'124353000', b'124353001')
try:
    pub.verify(sig, bad_msg,
        padding.PSS(mgf=padding.MGF1(hashes.SHA256()),
                    salt_length=padding.PSS.MAX_LENGTH),
        hashes.SHA256())
except Exception as e:
    print('改ざん検出:', type(e).__name__)

📤 実行例:

💬 結果の読み方: RSA-2048 の署名は 256 byte 固定長。 元メッセージで verify は成功するが、 1 byte でも改ざんしたメッセージで verify すると InvalidSignature が出る。 これが「総人口 124,353,000 という宣言は本人作成かつ無改ざんである」を数学的に保証する仕組み。

🐍 bcrypt + 塩で 47 県の管理者パスワードを安全保管

🎯 このコードでやること: SSDSE-B-2026 の各都道府県名から擬似「県職員パスワード」を生成し、 bcrypt（cost=12）でハッシュ化して保存。 同じパスワードでも毎回違うハッシュになる「塩の効果」を実測。

📥 入力データ: 都道府県名 47 件（例: 北海道, 青森県, ... 沖縄県）

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

import bcrypt
import pandas as pd

hdr = pd.read_csv('data/raw/SSDSE-B-2026.csv', encoding='cp932',
                  nrows=2, header=None).iloc[1].tolist()
df  = pd.read_csv('data/raw/SSDSE-B-2026.csv', encoding='cp932',
                  skiprows=2, header=None, names=hdr)
prefs = df[df['年度'] == 2023]['都道府県'].tolist()

# 1) 同じパスワード「admin」を 2 回ハッシュ化 → 違う結果
pw = b'admin'
h1 = bcrypt.hashpw(pw, bcrypt.gensalt(rounds=12))
h2 = bcrypt.hashpw(pw, bcrypt.gensalt(rounds=12))
print('h1:', h1[:40])
print('h2:', h2[:40])
print('一致?:', h1 == h2)
print('認証 h1:', bcrypt.checkpw(pw, h1))
print('認証 h2:', bcrypt.checkpw(pw, h2))

# 2) 47 県分の管理者ハッシュを生成
store = {p: bcrypt.hashpw((p + '_2026!').encode(), bcrypt.gensalt(12))
         for p in prefs[:3]}
for k, v in store.items():
    print(k, '→', v[:40])

📤 実行例:

💬 結果の読み方: 同じ「admin」でも塩が違うため h1 と h2 は別物（漏洩 DB から一斉解読不能）。 しかし checkpw は両方 True ＝ 認証は通る。 47 県分（実例は 3 県）にも適用可能。 cost=12 は 1 回あたり ≒ 0.3 秒、 攻撃者が 1 億回試すと約 1 年かかる調整。

⏱ 暗号化アルゴリズムのベンチマーク（実測値）

SSDSE-B-2026 (359,821 byte) を各アルゴリズムで暗号化したときの所要時間と出力サイズ。 数値は MacBook Pro M1 で実測の典型例。

大容量 CSV は共通鍵 (AES/ChaCha20)、 鍵交換は公開鍵 (RSA/ECC)、 パスワード保管は bcrypt/Argon2、 改ざん検知は SHA-256 ── と使い分けるのが定石。

🛡 SSDSE 教材で考える脅威モデル

SSDSE-B-2026 そのものは公開データなので暗号化は不要だが、 教材として「個人レベル住民データを SSDSE 形式に集計する前段階」を想定すると、 以下の脅威に対する防御を学べる。

🔁 ハイブリッド暗号 (TLS 風) を最小実装で追体験

HTTPS の中身を「RSA で AES 鍵を運び、 AES で本体を暗号化」という最小フローで体験する。 SSDSE-B-2026 ファイルをそのまま送ると仮定。

🎯 このコードでやること: 送信側 (Alice) が SSDSE CSV を AES-128 で暗号化、 その AES 鍵を受信側 (Bob) の RSA 公開鍵で暗号化して送る。 Bob は秘密鍵で AES 鍵を取り出し、 CSV を復号する。

📥 入力データ: 平文 = SSDSE-B-2026.csv (359,821 byte)、 受信者公開鍵 = RSA-2048

 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

from cryptography.fernet import Fernet
from cryptography.hazmat.primitives.asymmetric import rsa, padding
from cryptography.hazmat.primitives import hashes

# Bob の鍵ペア (受信者)
bob_priv = rsa.generate_private_key(65537, 2048)
bob_pub  = bob_priv.public_key()

# Alice: AES 鍵で平文 CSV を暗号化
aes_key = Fernet.generate_key()
fer     = Fernet(aes_key)
with open('data/raw/SSDSE-B-2026.csv', 'rb') as fp:
    plain = fp.read()
cipher_body = fer.encrypt(plain)

# Alice: AES 鍵を Bob の公開鍵で包む
wrapped_key = bob_pub.encrypt(aes_key,
    padding.OAEP(mgf=padding.MGF1(hashes.SHA256()),
                 algorithm=hashes.SHA256(), label=None))

# Bob: 秘密鍵で AES 鍵を解放 → CSV を復号
unwrapped = bob_priv.decrypt(wrapped_key,
    padding.OAEP(mgf=padding.MGF1(hashes.SHA256()),
                 algorithm=hashes.SHA256(), label=None))
restored = Fernet(unwrapped).decrypt(cipher_body)

print('wrapped_key 長:', len(wrapped_key),  'byte')
print('cipher_body 長:', len(cipher_body), 'byte')
print('復号一致?:', restored == plain)

📤 実行例:

💬 結果の読み方: AES 鍵 (32 byte) を RSA で包んだ wrapped_key はわずか 256 byte。 本体 CSV は 479,796 byte の暗号文。 もし全部 RSA で暗号化すると 100 倍以上遅くなる。 「鍵だけ RSA、 本体は AES」が現実のすべての TLS / SSH / PGP の基本パターン。

🐍 SSDSE 47 県名を AES-GCM (AEAD) で暗号化 + 改ざん検知

🎯 このコードでやること: AESGCM（認証付き暗号 = AEAD）で SSDSE の 47 県名を暗号化し、 暗号文を 1 byte 改ざんすると復号が失敗することを実演。

📥 入力データ: 47 都道府県名（北海道〜沖縄県）

 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

from cryptography.hazmat.primitives.ciphers.aead import AESGCM
import os, pandas as pd

hdr = pd.read_csv('data/raw/SSDSE-B-2026.csv', encoding='cp932',
                  nrows=2, header=None).iloc[1].tolist()
df  = pd.read_csv('data/raw/SSDSE-B-2026.csv', encoding='cp932',
                  skiprows=2, header=None, names=hdr)
prefs = df[df['年度'] == 2023]['都道府県'].tolist()

key   = AESGCM.generate_key(bit_length=256)
aes   = AESGCM(key)
nonce = os.urandom(12)     # 96 bit nonce 推奨
aad   = b'SSDSE-B-2026/year=2023/column=prefecture'

# 暗号化
payload = '|'.join(prefs).encode('utf-8')
cipher = aes.encrypt(nonce, payload, aad)
print('平文長:', len(payload), 'byte')
print('暗号文長:', len(cipher),   'byte (+16 byte が認証タグ)')

# 正常復号
restored = aes.decrypt(nonce, cipher, aad)
print('復号:', restored.decode()[:40], '...')

# 改ざん検知
tampered = cipher[:10] + bytes([cipher[10] ^ 0x01]) + cipher[11:]
try:
    aes.decrypt(nonce, tampered, aad)
except Exception as e:
    print('改ざん検知:', type(e).__name__)

📤 実行例:

💬 結果の読み方: 47 県名を | で連結した平文 478 byte（県名 144 文字 × UTF-8 3 byte + 区切り 46 byte）→ 暗号文 494 byte（+16 byte が GCM 認証タグ）。 1 byte 改ざんしただけで InvalidTag が出る。 AEAD (Authenticated Encryption with Associated Data) は暗号化と改ざん検知をワンパスで行うので、 別途 HMAC をかける必要がない。 TLS 1.3 が標準化したパターン。

🐍 SSDSE のチェックサムをまとめて記録するスクリプト

🎯 このコードでやること: data/raw/ 配下のすべての CSV について SHA-256 を計算し、 data/checksums.txt に記録。 後日 sha256sum -c で改ざん検知。

📥 入力データ: SSDSE-B-2026.csv ほか raw/ 配下の任意 CSV

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

import hashlib, pathlib

raw_dir   = pathlib.Path('data/raw')
out_path  = pathlib.Path('data/checksums.txt')

lines = []
for p in sorted(raw_dir.glob('*.csv')):
    digest = hashlib.sha256(p.read_bytes()).hexdigest()
    lines.append(f'{digest}  {p.name}')

out_path.write_text('\n'.join(lines))
print('書き出し:', out_path, '行数:', len(lines))
for ln in lines[:3]:
    print(ln)

📤 実行例:

💬 結果の読み方: data/raw 配下の CSV を全部走査するので、 出力行数はそのフォルダに置いてある CSV の数だけになる（この教材では SSDSE-A の各年版を含めて 11 本）。 ファイルを追加・削除すれば行数も変わるので、 固定の数字として読まないこと。 data/checksums.txt は GitHub にコミット可能（CSV 本体より遥かに小さい）。 後日 sha256sum -c data/checksums.txt を走らせれば、 配下の CSV が変質していないか自動チェック。 SSDSE のような数年分の公的データを継続管理するときの基本作法。

✅ 暗号化の習得チェックリスト（30 項目）

1. 共通鍵と公開鍵の違いを 1 分で説明できる
2. AES-128 / 256 の鍵長の単位とラウンド数を覚えている
3. ECB モードの危険性を「ペンギン画像」の例で説明できる
4. GCM が AEAD であり、 認証タグ 16 byte が付くことを知っている
5. RSA の安全性が素因数分解の困難性に基づくことを説明できる
6. 公開指数 $e=65537$ がよく使われる理由を知っている
7. ECC の鍵長 256 ビットが RSA-3072 ビット相当なのを知っている
8. SHA-256 が 32 byte 出力で、 雪崩効果を持つことを実感した
9. bcrypt の cost factor の意味と推奨値（12 以上）を知っている
10. Argon2 が bcrypt より新しい標準であることを認識している
11. TLS 1.3 のハンドシェイクが 1-RTT であることを知っている
12. X25519 と P-256 (ECDH) の違いを大まかに知っている
13. Let's Encrypt の証明書が 90 日有効であることを知っている
14. HKDF が「鍵から複数の鍵を派生させる関数」であることを説明できる
15. X.509 証明書のチェーン検証手順を説明できる
16. OCSP / CRL の役割（証明書失効確認）を知っている
17. HMAC-SHA256 の安全性根拠を説明できる
18. JWT のヘッダ・ペイロード・署名構造を知っている
19. HS256 と RS256 の使い分けを知っている
20. パスワードレス認証 (FIDO2/Passkey) の仕組みを知っている
21. KMS と HSM の違いを説明できる
22. Envelope encryption（KEK + DEK）の利点を説明できる
23. 差分プライバシーの ε パラメータの意味を知っている
24. k-匿名化と差分プライバシーの違いを説明できる
25. 同型暗号 (HE) の用途と現状の性能を知っている
26. ML-KEM / ML-DSA / SLH-DSA の用途を区別できる
27. サイドチャネル攻撃の概念（タイミング・電力）を知っている
28. 個人情報保護法における暗号化の位置づけを説明できる
29. 暗号化ライブラリ cryptography の Fernet / AESGCM を実装できる
30. SSDSE データのチェックサムを生成・検証できる

📊 SSDSE-B-2026 から派生する「暗号化の必要性」統計

SSDSE-B-2026 (2023 年度) から計算される実値で、 「なぜ個人レベルデータには暗号化が必須か」を裏付ける。

この種の値は、 暗号化を語るときに「なんとなく重要」ではなく「47 県中 11% が東京、 0.43% が鳥取という非対称構造があるからこそ暗号化が必要」と数字で論じる材料になる。

📝 まとめ — 暗号化と SSDSE 教材

1. 暗号化 = 鍵で戻せる変換、 ハッシュ化 = 戻せない変換。 用途で使い分け。
2. 共通鍵 (AES) は速い、 公開鍵 (RSA/ECC) は鍵交換と署名用。 実運用は両者のハイブリッド。
3. SSDSE-B-2026 (359,821 byte) を AES で 1 ms、 全 RSA だと 60 秒 ── これがハイブリッド必須の根拠。
4. SHA-256 の雪崩効果で 1 byte 改ざんも検知。 SSDSE 配布時のハッシュ併記が標準。
5. パスワード保管は bcrypt/Argon2 + 塩。 SHA-256 単独は NG。
6. 鍵管理が漏洩の本丸。 KMS / HSM / Envelope encryption を学ぶ。
7. TLS 1.3 が現代標準。 SSDSE を HTTPS で取得する全工程に暗号が埋め込まれている。
8. ポスト量子暗号への移行が 2024 年 NIST 標準化で本格化。 長期保管データは ML-KEM / ML-DSA を検討。
9. 暗号化 ≠ 匿名化。 個人情報保護法・GDPR では暗号化データも個人情報。 匿名加工との組合せが必要。
10. SSDSE 教材で暗号化を教えるときは、 「公開データそのものは不要だが、 個人データを組み込む実務では必須」と位置づける。

🔗 暗号化と他用語の交差点（用語集内ナビ）

暗号化は単独で完結する概念ではなく、 セキュリティ・プライバシー・データ倫理の交点に位置する。 本サイト内の関連ページとの関係を整理する。

これらのページを横断することで、 「暗号化を点ではなく、 セキュリティ・プライバシー・データ倫理の網の中の交点として理解できる」ようになる。

📇 クイックリファレンス (実務逆引き)

このカードを手元に持っておけば、 SSDSE データを使った研究・教育の現場で「とりあえずどれを使えば？」に即答できる。

📮 暗号化を学ぶ次の一歩

本ページで「暗号化とは何か」「SSDSE-B-2026 実値でどう動くか」「どんなライブラリ・モード・落とし穴があるか」を一気通貫で押さえた。 次に進むなら、 以下の経路が効率的。

1. ハッシュ関数 ページで一方向関数の数学的性質を深掘り
2. 電子署名 で公開鍵暗号の応用編へ
3. 認証 と なりすまし で「鍵が漏れた後の世界」を学ぶ
4. API ページで JWT / OAuth / TLS の実装を確認
5. 差分プライバシー で「暗号化では守れない統計的漏洩」を理解
6. 外部資料: NIST SP 800-175B（米国政府暗号要件）、 CRYPTREC 推奨暗号リスト 2024
7. 書籍: Katz & Lindell『Introduction to Modern Cryptography』（数学派）、 Schneier『Applied Cryptography』（実装派）

SSDSE-B-2026 を題材にした統計・データ解析コンペの論文を書くとき、 「データ取得と倫理」章に本ページの内容（HTTPS でのダウンロード、 SHA-256 でのファイル指紋検証、 個人情報併用時の列暗号化）を 1〜2 段落入れるだけで、 査読者に「暗号化と倫理を理解している研究者」という印象を与えられる。

🔐 補論: 対称鍵暗号と公開鍵暗号の使い分け（SSDSE-B-2026 配布シナリオ）

本ページの本文では「暗号化とは何か」を扱ったが、 ここでは SSDSE-B-2026 (47 都道府県 × 124 列) を共同研究者に配布する 具体的シナリオで、 対称鍵 (AES-256-GCM) と公開鍵 (RSA-4096 / Curve25519) のどちらを使うべきかを整理する。 「数式を言葉で読み解く」の節で扱った概念を実務に落とす。

🎯 シナリオ比較表

🐍 Python 実装: SSDSE-B-2026 をハイブリッド暗号化して送信する

このコードでやること: SSDSE-B-2026 (47 都道府県 × 124 列、 約 80 KB の CSV) を、 共同研究者の RSA 公開鍵で暗号化した AES-256 セッション鍵で守って送る。 これが TLS や PGP の中身と同じ仕組み。

📥 入力データ: SSDSE-B-2026.csv (47 行、 都道府県別データ) と相手の公開鍵 collab_pub.pem (RSA-4096)。

 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

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

# 1. SSDSE-B-2026 を読んで CSV バイト列にする
df = pd.read_csv('data/raw/SSDSE-B-2026.csv', encoding='cp932')
plaintext = df.to_csv(index=False).encode('utf-8')

# 2. AES-256 のセッション鍵を 1 回だけ生成 (32 バイト = 256 bit)
session_key = AESGCM.generate_key(bit_length=256)
aesgcm = AESGCM(session_key)
nonce = os.urandom(12)
ciphertext = aesgcm.encrypt(nonce, plaintext, associated_data=b'SSDSE-B-2026')

# 3. 相手の RSA 公開鍵で session_key を包む (= ハイブリッド暗号)
#    本来は相手から受け取った公開鍵ファイルを読む。
#    ここでは動かせるように、その場で鍵の組を作る。
from cryptography.hazmat.primitives.asymmetric import rsa
priv = rsa.generate_private_key(public_exponent=65537, key_size=2048)
pub = priv.public_key()
wrapped_key = pub.encrypt(
    session_key,
    padding.OAEP(mgf=padding.MGF1(hashes.SHA256()),
                 algorithm=hashes.SHA256(), label=None)
)
print(f'ciphertext: {len(ciphertext)} bytes, wrapped_key: {len(wrapped_key)} bytes')

📤 実行例:

💬 SSDSE-B-2026 本体 (UTF-8 の CSV にすると約 354 KB = 361,942 バイト。 これに GCM 認証タグ 16 バイトが付いて 361,958 バイト) は AES-256-GCM で高速に暗号化され、 32 バイトのセッション鍵だけを RSA-2048 (鍵長 2048 bit = 256 バイトの暗号文) で包む。 本体が何 MB になっても wrapped_key は鍵長で決まる 256 バイトのままである点が、 ハイブリッド方式の要。 受信側は自分の秘密鍵で wrapped_key を復号 → session_key を取り戻して本体を AES 復号する。 これが PGP・TLS・S/MIME 全てに共通する仕組みである。

⚠️ 補論の落とし穴

• nonce の再利用は致命的: AES-GCM では同じ鍵で同じ nonce を 2 回使うと、 過去の暗号文も平文に復元できる事故が起きる。 os.urandom(12) で毎回新規生成すること。
• RSA で大きなデータを直接暗号化しない: 上のコードの RSA-2048 + OAEP(SHA-256) は最大 190 バイト、 RSA-4096 でも最大 446 バイトまでしか暗号化できない。 354 KB の SSDSE-B-2026 を直接 RSA にかけるのは設計ミス。 必ずハイブリッド方式（AES で本体、 RSA でセッション鍵）にする。
• 公開鍵の真正性確認を忘れない: メールで送られてきた collab_pub.pem がそのまま信用できるとは限らない。 別経路（電話・対面）で sha256sum collab_pub.pem の値を読み合わせる。

🖼 補足: 暗号化フローの全体像を可視化で押さえる

暗号化は概念が抽象的なため、 各段階を可視化で押さえることが理解の早道です。 SSDSE-B-2026 のような実データを暗号化して保管・送信する場面を念頭に、 3 つの図でフロー全体を整理します。

これら 3 図で暗号化の 「何を、 どのアルゴリズムで、 どのくらいのコストで」 守るかが視覚的に整理できます。 SSDSE-B-2026 のような公開データには暗号化は不要ですが、 個人情報を含むデータ (たとえば家計調査・国勢調査の個票) を扱う場面では、 暗号化が必須となります。 その際、 ここで示した 3 つの観点で技術選択を行うのが定石です。

✅ 理解度チェック

1. 対称鍵暗号 (AES) と非対称鍵暗号 (RSA) のもっとも本質的な違いは何か？
2. AES-GCM の nonce を再利用するとなぜ危険か？
3. SSDSE-B-2026 の個票データを社内共有するときに、 ハイブリッド暗号 (RSA + AES) を使う理由は？
4. 暗号文の分布が一様に近いことが「正常」と言える理由は？
5. 暗号アルゴリズムの「鍵長」と「実際の安全性」は単純に比例するか？

→ すべて即答できれば、 暗号化の基本概念は十分。 不安な項目は本ページの該当セクションを再読してください。

📝 補足: 暗号化の実務 3 シナリオ

暗号化は使うシーンによって設計が大きく変わります。 「保管」、 「通信」、 「共有」 の 3 シナリオを、 SSDSE-B-2026 を念頭に整理します。

シナリオ A: データの保管時暗号化 (Encryption at Rest)

クラウドストレージや社内 NAS にデータを保存する際の暗号化です。 SSDSE-B-2026 のような公開データは暗号化不要ですが、 個人情報を含むデータは 必ず暗号化 して保管します。 一般的には AES-256 で本文を暗号化し、 鍵管理は KMS (Key Management Service) に委ねるのが定石。 自前で鍵を管理しようとすると、 鍵紛失・流出時にデータ全消失の事故になります。 AWS KMS・Azure Key Vault・Google Cloud KMS いずれも、 鍵そのものを HSM (ハードウェアセキュリティモジュール) で守ります。

シナリオ B: 通信時暗号化 (Encryption in Transit)

API 経由でデータを送受信する際の暗号化です。 HTTPS (TLS 1.3) が標準で、 ブラウザの「鍵マーク」で確認できます。 TLS の内部では、 まず ECDHE で鍵共有を行い、 共有された対称鍵で AES-GCM や ChaCha20-Poly1305 でデータを暗号化します。 SSDSE-B-2026 を e-Stat API から取得する場合、 これらの仕組みが自動で動くため、 利用者は意識する必要はありません。 ただし、 古い TLS 1.0/1.1 を使うレガシーシステムでは脆弱性があるため、 必ず TLS 1.2 以上を使う設定にしましょう。

シナリオ C: 個別共有時の暗号化

特定の相手にだけデータを渡す場合の暗号化です。 GPG (PGP) や age (アゲ) などの公開鍵暗号ツールが定番。 相手の公開鍵で暗号化し、 相手は自分の秘密鍵で復号する。 SSDSE-B-2026 の個票を研究協力者に渡す場合などに使います。 ただし、 公開鍵の真正性確認 (受け取った鍵が本当に相手のものか) を別経路でしっかり行うことが必須。 「電話で fingerprint を読み合わせる」 のが古典的だが最も信頼できる方法です。

これら 3 シナリオを使い分けると、 暗号化は単なる「データを隠す技術」 ではなく、 「データのライフサイクル全体を守る設計」 として扱えるようになります。 SSDSE-B-2026 のような公開データを扱う段階では暗号化は不要ですが、 実務で個人情報・営業秘密を扱う場面では、 これら 3 シナリオの判断を即座に下せる感覚が必須です。

追加 Tips: 暗号化と鍵管理の難しさ

暗号化アルゴリズム自体は枯れて安全ですが、 鍵管理 が常に弱点です。 鍵をどう保管し、 どうローテーションし、 どう失効させるか。 これらは技術というより組織と運用の問題で、 KMS や HSM を導入したとしても、 「誰が鍵を使えるか」 のアクセス制御を間違えると一発で漏洩します。 IAM・RBAC との連携、 監査ログの保管、 鍵ローテーション (年 1 回程度)、 失効時の影響範囲分析、 これらすべてが暗号化運用の本体です。

また、 量子コンピュータの台頭により、 現行の RSA・ECDSA は将来的に破られる可能性があります。 NIST が 耐量子暗号 (PQC, Post-Quantum Cryptography) の標準化を進めており、 CRYSTALS-Kyber (鍵共有)、 CRYSTALS-Dilithium (署名) などが採用されました。 SSDSE-B-2026 のような短期データには影響しませんが、 数十年保管が必要な医療データや国家機密では、 すでに耐量子暗号への移行 (ハイブリッド方式) が始まっています。 今後 5 〜 10 年で大規模に置き換わる見込みなので、 動向をチェックしておく価値があります。

最後に、 暗号化は 「自分で実装しない」 ことが鉄則です。 標準ライブラリ (Python の cryptography パッケージなど) や OS 標準のツール (OpenSSL、 GnuPG) を使い、 自前で AES や RSA を実装することは絶対に避けてください。 暗号化の自前実装は、 サイドチャネル攻撃・タイミング攻撃・乱数品質の問題などで容易に脆弱になります。 SSDSE-B-2026 を題材に暗号化を学ぶ際も、 必ず標準ライブラリ経由で実装するようにしましょう。

追加 Tips: 暗号化と法律・コンプライアンス

暗号化は技術問題だけでなく、 法的・コンプライアンス的な側面も持ちます。 日本では 個人情報保護法、 EU では GDPR、 米カリフォルニア州では CCPA が、 個人情報を扱う事業者に対して暗号化を実質的に求めています。 とくに GDPR は罰則が重く、 違反すると年間売上の 4% または 2,000 万ユーロのいずれか大きい方が制裁金として課されます。 SSDSE-B-2026 のような公開統計は対象外ですが、 個票データ・顧客データを扱う場合は必ず確認すべきです。

また、 国家機密や軍事用途の暗号化は 輸出管理 の対象になります。 米国では Bureau of Industry and Security が、 日本では経済産業省が、 強力な暗号化技術の輸出を規制しています。 通常のソフトウェア開発で気にする必要は少ないですが、 グローバル企業の暗号化製品を扱うときは要注意です。 また、 中国・ロシアなど一部国家では 暗号化禁止・規制 の動きがあるため、 海外拠点で運用する場合は事前調査が必須です。

追加 Tips: ハッシュと暗号化の違い

混同されがちですが、 ハッシュは暗号化ではありません。 ハッシュ (SHA-256 など) は一方向で、 復号できません。 主にデータの完全性確認 (改ざん検知)、 パスワード保存 (実際は salt + ハッシュ)、 デジタル署名の事前処理に使われます。 暗号化は復号できる双方向の処理で、 機密性を守るのが目的。 SSDSE-B-2026 のファイルが改ざんされていないかを確認するには sha256sum で、 内容を秘匿するには openssl enc で AES 暗号化、 と使い分けます。

パスワード保存に MD5 や SHA-1 を直接使うのは古典的な失敗パターン。 現代では bcrypt・scrypt・argon2 といった キーストレッチング 関数を使い、 計算コストを意図的に高めて総当たり攻撃を防ぎます。 これも 「自分で実装しない」 の原則が適用される領域で、 必ず標準ライブラリ経由で使いましょう。

暗号化を学ぶ次のステップ

本ページで暗号化の基礎・実務 3 シナリオ・運用面の注意点を押さえました。 次に学ぶべきは 公開鍵暗号 (RSA/ECDSA の深掘り)、 認証 (鍵管理・MFA)、 サイバーセキュリティ (暗号化を包括する設計) です。 これらを順に押さえると、 暗号化を「データを隠す技術」 から 「組織のセキュリティ設計の中核」 として扱えるようになります。

並行して、 改ざん・可用性・アクセス管理 の各用語ページを巡回すると、 「機密性・完全性・可用性 (CIA トライアド)」 のセキュリティ三要素を体系的に理解できます。 暗号化は CIA のうち主に「機密性」と「完全性」を担保する技術で、 「可用性」は別の領域 (バックアップ・冗長化) で担保するのが原則です。 この区別が分かると、 セキュリティ設計の視野が一気に広がります。

最後に、 暗号化は 「使う技術」 であり 「学ぶ技術」 ではない という現実的な視点を強調します。 暗号化の理論 (数論・群論・楕円曲線) は深く美しいですが、 実務で必要なのは「正しい標準ライブラリを正しいパラメータで使う」 力です。 SSDSE-B-2026 のような実データで cryptography パッケージを使って暗号化・復号する練習を 1 度通せば、 実務に直結する力が身につきます。 それ以上の理論は、 必要が生じた時点で学べば十分です。

暗号化の歴史的背景と現代的位置づけ

暗号化の歴史は古代エジプト・古代ローマまで遡り、 シーザー暗号 (アルファベットを 3 文字ずらす単純な置換) が最古の体系的な暗号として知られます。 中世にはアラビアで頻度解析が発明され、 単純な置換暗号は簡単に破られるようになりました。 第二次世界大戦中の Enigma 機の暗号と、 それを破った Bletchley Park の暗号解読チーム (Alan Turing 含む) は、 現代計算機科学の出発点でもあります。

現代暗号 (公開鍵暗号) は 1976 年の Diffie-Hellman 鍵共有、 1977 年の RSA 発明で始まりました。 これにより 「事前に鍵を共有していない相手とも安全に通信できる」 という画期的な仕組みが実現し、 後のインターネット商取引 (TLS/SSL) の基盤となりました。 1990 年代後半に AES (元の名前は Rijndael) が標準化され、 現代の対称鍵暗号の主役となっています。

2020 年代になると、 準同型暗号 (暗号化したまま計算できる) や ゼロ知識証明 (情報を明かさずに正しさを証明する) といった新しい暗号技術が実用化されつつあります。 これらはプライバシー保護機械学習・分散型システム (Web3)・電子投票などに応用が始まっており、 暗号化の領域がデータサイエンスと直接結びつくようになっています。 SSDSE-B-2026 のような公開データでは恩恵が見えにくいですが、 医療データ・金融データを扱う場面では、 これらの新技術が今後ますます重要になります。

追加 Tips: 暗号化と性能・運用コスト

暗号化には CPU コスト・メモリコスト・運用コストがかかります。 AES-GCM は CPU 上で 1GB/秒以上の速度が出る (AES-NI 命令対応 CPU の場合) ので、 大規模データでもボトルネックになりにくい。 一方 RSA の鍵生成や署名は遅く、 大量の処理を行う場合は ECDSA への移行を検討します。 SSDSE-B-2026 のような数 MB のデータなら、 どのアルゴリズムでも瞬時に処理が終わります。

運用コストの方が技術コストより重く、 鍵管理・証明書更新・ローテーション・監査などの作業が継続的に発生します。 KMS を使うとこの大半を委ねられますが、 月額料金がかかります。 SSDSE-B-2026 規模のデータでは KMS の費用 (月数百円〜) は無視できる程度ですが、 数百万件の鍵を管理する場合は月数十万円〜数百万円になります。 暗号化を導入する際は、 必ず運用コストも含めた総コストで判断してください。

最後に、 暗号化は 「導入すれば終わり」 ではなく 「継続的な運用が始まる」 技術であることを強調します。 SSDSE-B-2026 のような短期プロジェクトでは導入だけで足りますが、 長期運用するシステムでは、 鍵ローテーション・アルゴリズム更新・脆弱性対応が継続的に必要です。 暗号化の運用を軽視すると、 数年後に脆弱な暗号化で守られているのと同等のリスクを抱えることになります。 暗号化の導入時点で、 5 年後・10 年後の運用計画を立てておくことを強く推奨します。

追加 Tips: 暗号化と認証の関係

暗号化と認証はしばしばセットで扱われますが、 別概念です。 暗号化 は内容を隠す技術、 認証 は身元を確認する技術。 たとえば AES-GCM は本文を暗号化 (機密性) しつつ、 認証タグで改ざん検知 (完全性) も同時に行います。 これが「認証付き暗号化 (AEAD, Authenticated Encryption with Associated Data)」 と呼ばれる仕組みで、 現代の暗号化の標準形です。

古い CBC モードや CTR モードを単独で使う場合、 暗号化だけで認証がないため、 改ざんを検知できません。 これを補うために HMAC を別途付けるのが伝統的な方法ですが、 「Encrypt-then-MAC」 の順序を守らないと脆弱になります。 現代では GCM や ChaCha20-Poly1305 などの AEAD モードを使う のが鉄則で、 自分で「暗号化 + HMAC」 を組み合わせる実装は避けるべきです。 SSDSE-B-2026 で暗号化のサンプルを試す際も、 必ず AEAD モードを選んでください。

暗号化のチェックリスト (実務版)

• 標準ライブラリを使っているか (自前実装していないか)
• AEAD モードを使っているか (GCM / ChaCha20-Poly1305)
• 鍵長は十分か (AES-256, RSA-2048 以上)
• nonce / IV は毎回ユニークか
• 鍵は KMS で管理しているか
• 鍵ローテーション計画があるか
• TLS 1.2 以上を使っているか
• HTTPS の証明書は自動更新されているか
• 監査ログは保管されているか
• 耐量子暗号への移行計画は意識しているか

このチェックリストを SSDSE-B-2026 では使う機会はありませんが、 実務で暗号化を扱う際に必ず通すべきポイントです。 これらをすべて満たしていれば、 暗号化に関する基本的な事故はほぼ防げます。 暗号化は奥が深い領域ですが、 「使う技術」 として割り切れば、 これらのチェックリストで十分実用に耐えます。

暗号化と組織の役割分担

大規模な組織では、 暗号化は単独のエンジニアが担当するものではなく、 セキュリティチーム、 インフラチーム、 開発チームの連携で実現されます。 セキュリティチームが「何を、 どのレベルで、 どんなアルゴリズムで」 守るかのポリシーを定め、 インフラチームが KMS や HSM を運用し、 開発チームがアプリケーションコードで標準ライブラリを正しく使う、 という分業が典型的。 SSDSE-B-2026 のような個人プロジェクトでは 1 人で全部こなしますが、 大規模化したら役割分担を意識することで、 暗号化の運用ミスが減ります。

また、 ペネトレーションテスト (侵入テスト) と外部監査を定期的に受けることで、 自分達では気付かない弱点を発見できます。 PCI DSS (クレジットカード業界)、 ISO 27001、 SOC 2 などの認証取得は、 暗号化を含むセキュリティ対策が組織的に運用されていることの第三者証明となり、 取引先からの信頼を獲得する手段にもなります。 SSDSE-B-2026 のような学習用途では関係ありませんが、 商用サービスでは必須となる場面が多いです。

暗号化は技術・運用・組織の三層構造で成り立っており、 どの層が欠けてもセキュリティは脆くなります。 SSDSE-B-2026 のような小規模学習プロジェクトから始めて、 徐々に大規模システムでの暗号化運用を経験することで、 この三層構造を実感として理解できるようになります。 最初は標準ライブラリで小さく動かしてみる、 次に KMS で鍵管理を体験する、 さらに次に組織のセキュリティポリシーに沿った運用を担当する、 という段階的な学習が現実的なキャリアパスです。 焦らず一段ずつ進んでください。 そしてどの段階でも、 「暗号化は単なるおまじないではなく、 データのライフサイクル全体を守る設計」 だという視点を忘れないことが大切です。 この視点を持って実務に臨めば、 セキュリティに対する組織内での信頼を確実に獲得できます。 SSDSE-B-2026 で身につけた基本感覚は、 そのまま大規模システムの暗号化運用にも応用可能であり、 学習投資の費用対効果が非常に高い領域です。 ぜひ実際に手を動かし、 自分なりの暗号化運用ポリシーを 1 つ作り上げてください。 そのポリシーが、 セキュリティに対する組織の信頼を支える基盤になります。 学習の継続が、 最終的に実務での安全性を担保する力につながります。 短期的には地味ですが、 長期的にはキャリアの基盤になる投資です。 暗号化を 「使える」 人材は、 どの業界でも常に需要があるため、 学習価値は非常に高いと言えます。 SSDSE-B-2026 を題材にした基礎学習からスタートし、 一歩ずつ実務スキルを積み上げてください。 そして毎年技術トレンドを追い続けることで、 自分の知識を陳腐化させずに維持できます。 暗号化の世界は変化が激しいので、 RSS や Twitter で NIST・IETF・主要研究機関の発表を追うのが効率的です。 学会論文 (Eurocrypt・Crypto・Asiacrypt) も年に 1 度はチェックすると、 次の 5 年で実用化される技術が見えてきます。 これら情報源を継続的に追うことで、 自分の暗号化スキルを最新状態に保てます。 そして実務での適用が、 知識を真の力に変える唯一の方法です。 実データで手を動かすこと、 これに勝る学習法はありません。 ぜひ SSDSE-B-2026 を題材に最初の一歩を踏み出してください。 そこから次のステップへ自然と進めるはずです。 学習は段階的に、 そして継続的に進めていきましょう。

⚠️ よくある落とし穴

❓ よくある質問（FAQ）

📜 歴史と背景

歴史と位置づけ：暗号の歴史は古代ローマのシーザー暗号にまで遡りますが、 数学的体系化は 20 世紀。 主要な節目：

• 1949 — Shannon が情報理論的安全性（Perfect Secrecy）を定義
• 1976 — Diffie & Hellman が「公開鍵暗号」の概念を提案
• 1977 — Rivest, Shamir, Adleman が RSA を発表
• 1985 — Koblitz と Miller が独立に 楕円曲線暗号 (ECC)を提案
• 2001 — AES が NIST 標準として採択（Rijndael）
• 2009 — Gentry が完全準同型暗号 (FHE) を構成可能と証明
• 2010 年代 — ポスト量子暗号（格子・符号・多変数）の標準化が始動
• 2024 — NIST がポスト量子暗号標準 ML-KEM, ML-DSA, SLH-DSA を公開

データサイエンスとの接点は、 (1) 個人情報を扱う前提技術として、 (2) プライバシー保護機械学習（連合学習・同型暗号・差分プライバシー）、 (3) ブロックチェーン上の改ざん不能データ、 の 3 方向に広がっています。

🌐 関連手法・派生・対概念

🌐 TLS 1.3 の中身を SSDSE データ取得シナリオで追体験

研究者がブラウザで https://www.nstac.go.jp/SSDSE/SSDSE-B-2026.csv を開いたとき、 暗号は次の順序で動く。

1. ClientHello: ブラウザがサポートする暗号スイート（例: TLS_AES_256_GCM_SHA384）と、 X25519 一時公開鍵を送信。
2. ServerHello: サーバが暗号スイートを選択し、 X25519 一時公開鍵 + 証明書（Let's Encrypt 等）を返す。
3. 鍵共有 (ECDHE): 双方の X25519 から共通鍵（pre-master secret）を導出。 サーバの長期秘密鍵には依存しないので、 後日鍵が漏洩しても過去通信は復号できない（前方秘匿性 PFS）。
4. HKDF: pre-master secret から複数の派生鍵（暗号化鍵・MAC 鍵・IV）を導出。
5. 本体通信: SSDSE CSV (359,821 byte) を AES-256-GCM で暗号化して送る。
6. 受信: ブラウザが復号・タグ検証して保存。

TLS 1.3 のハンドシェイクは 1-RTT（往復 1 回）で完了。 1.2 までは 2-RTT 必要だった。 0-RTT モードも追加されたが再送攻撃リスクと引き換え。

暗号スイートの命名規約

SSDSE 取得 API を自前で立てるなら（Python + nginx）

1. nginx を Let's Encrypt 証明書で TLS 1.3 化（5 行の設定）
2. Python (FastAPI) で SSDSE CSV を返すエンドポイントを実装
3. API キー認証（HMAC-SHA256 で署名検証）
4. レートリミット（Redis でカウンタ）
5. ログに X-Forwarded-For を記録、 異常検知へ

これだけで「暗号化通信 + 認証 + ログ」の最小構成。 SSDSE 規模なら CDN は不要、 単一 VPS で数万 req/秒さばける。

🗝 鍵管理 (KMS / HSM) の運用パターン

「暗号化アルゴリズム」よりも漏洩の本丸は鍵管理。 SSDSE 教材で扱う場合の参照アーキテクチャ:

パターン 1: シングルファイル暗号化（最小）

• 鍵 = ランダム 32 byte、 環境変数 DATA_KEY に格納
• 適用範囲: 個人検証用、 単一マシン
• リスク: マシン侵入で即漏洩

パターン 2: 鍵階層（KEK + DEK / Envelope Encryption）

• DEK (Data Encryption Key) = データごとに 1 つ、 AES-256
• KEK (Key Encryption Key) = DEK を暗号化するための鍵、 KMS / HSM 内に保管
• 適用範囲: クラウド (AWS S3 SSE-KMS, GCP CMEK)
• 利点: KEK のローテーションで再暗号化最小化、 鍵の責任分離

パターン 3: HSM (Hardware Security Module)

• 鍵は物理デバイス内に格納、 外には絶対出ない（FIPS 140-2 Level 3+）
• 適用範囲: 金融、 政府、 認証局（CA）
• マイナンバーカードの IC チップは個人 HSM とも言える

パターン 4: しきい値共有 (Threshold / Shamir Secret Sharing)

• 鍵を $n$ 個に分割、 $k$ 個集まれば復元可能（例: 5 人中 3 人で復号）
• 適用範囲: 取締役会承認が必要な機密、 ブロックチェーンマルチシグ

鍵ローテーション周期の目安

🔎 解説深化: 直感・落とし穴・発展を一枚に

ここまでの各節を、 「暗号化とは何をしているのか」という 1 本の軸で結び直す補足セクションです。 既存の説明と重複する部分もありますが、 直感 → 落とし穴 → 発展の順に俯瞰できるよう再整理しました。

🎨 直感（もう一度、 核心だけ）

暗号化とは、 平文（読める元データ）を鍵で暗号文（第三者には読めない形）へ変換し、 正しい鍵を持つ者だけが復号できるようにすることです。 守っているのは主に機密性 (confidentiality)——「盗み見られても中身が分からない」という性質です。 鍵の使い方で 2 系統に分かれます。

• 対称鍵（共通鍵）暗号: 暗号化と復号で同じ鍵を使う。 速い・大容量向き。 例: AES。 弱点は「鍵をどう相手に渡すか」（鍵配送問題）。
• 非対称鍵（公開鍵）暗号: 公開鍵で暗号化・秘密鍵で復号という別々の鍵を使う。 鍵配送問題を解けるが遅い。 例: RSA・楕円曲線。

実際の通信は両者を組み合わせたハイブリッド暗号（公開鍵で共通鍵を届け、 本体は共通鍵で暗号化）が定番で、 HTTPS / TLS がその代表です。

⚠️ 落とし穴（重要 — ここを外すと暗号化は無意味）

🚀 発展（暗号化を取り巻く技術の地図）

データサイエンスの文脈（＝個人情報を含むデータの保護）では、 暗号化は単独ではなく、 匿名加工・k-匿名化・差分プライバシーと組み合わせて初めて実運用に足りる点に注意してください。 参考: 本ページ実測の SSDSE-B-2026 CSV は 359,821 byte、 SHA-256 指紋は 0fdbe5f603bb…（改ざん検知の基準値）。

🔗 関連ページ（用語集内）

より深く学ぶための、 用語集内の実在ページへのリンクです（存在しない用語はテキストで示します）。

※ 用語集内に専用ページが未整備のため本文テキストで示す関連語: ハッシュ関数、 鍵交換 (Diffie-Hellman)、 ゼロ知識証明、 準同型暗号、 ポスト量子暗号、 乱数 (CSPRNG)、 TLS / HTTPS。

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

📘 前提となる用語

🤝 並列・関連する用語

🚀 発展・応用

📚 関連グループ教材

このページの内容を、より広い文脈で学びたいときは：

• 📚 データ倫理 — 個人情報保護と透明性の原則
• 📚 セキュリティ — 暗号と認証の体系
• 📚 AI ガバナンス — プライバシー保全と AI 利活用

📚 参考文献・出典

• Stallings, W. (2017). Cryptography and Network Security, 7th ed. Pearson.
• Katz, J., Lindell, Y. (2014). Introduction to Modern Cryptography. CRC Press.
• NIST (2024). FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), FIPS 205 (SLH-DSA).
• 個人情報の保護に関する法律（個人情報保護法）令和 5 年改正

🗺 学習ロードマップ

🗺 学習ロードマップ

1. レベル 1 — 共通鍵 vs 公開鍵、 ハッシュ関数の役割を区別。
2. レベル 2 — Fernet で AES 暗号化、 SHA-256 でハッシュ。 Python の cryptography ライブラリ。
3. レベル 3 — RSA 鍵生成、 電子署名、 検証。
4. レベル 4 — TLS の仕組み、 X.509 証明書、 認証局（CA）。
5. レベル 5 — 鍵管理（KMS、 HSM）、 ローテーション、 セッション暗号、 PFS。
6. レベル 6 — 同型暗号、 ゼロ知識証明、 ポスト量子暗号（PQC）、 連合学習。

📊 比較表（兄弟手法・選択肢）

主要暗号アルゴリズムの比較

📖 用語ミニ辞典

🍳 コードレシピ（コピペ用 15 連発）

1
2

from cryptography.fernet import Fernet
key = Fernet.generate_key()

f = Fernet(key); ct = f.encrypt(b'secret')

pt = f.decrypt(ct)

1

import hashlib; hashlib.sha256(b'hello').hexdigest()

with open('a.csv','rb') as f: hashlib.sha256(f.read()).hexdigest()

1

import bcrypt; h = bcrypt.hashpw(b'pw', bcrypt.gensalt(12))

bcrypt.checkpw(b'pw', h)

1
2

from cryptography.hazmat.primitives.asymmetric import rsa
priv = rsa.generate_private_key(65537, 2048)

sig = priv.sign(msg, padding.PSS(...), hashes.SHA256())

priv.public_key().verify(sig, msg, padding.PSS(...), hashes.SHA256())

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

import os
from cryptography.hazmat.primitives.ciphers.aead import AESGCM

# key / nonce / pt / aad をここで用意する（AESGCM の鍵は 128/192/256 bit）
key = AESGCM.generate_key(bit_length=256)
nonce = os.urandom(12)
pt  = '暗号化したい本文'.encode('utf-8')
aad = b'SSDSE-B-2026'

from cryptography.hazmat.primitives.ciphers.aead import AESGCM
aesgcm = AESGCM(key); ct = aesgcm.encrypt(nonce, pt, aad)

1

import hmac, hashlib; h = hmac.new(key, msg, hashlib.sha256).hexdigest()

1

import secrets; salt = secrets.token_bytes(16)

secrets.token_urlsafe(32)

1
2

from argon2 import PasswordHasher
ph = PasswordHasher(); hash_ = ph.hash('pw')

暗号関連技術の俯瞰：

              ［暗号化］
                 │
    ┌────────────┼────────────┐
共通鍵          公開鍵         ハッシュ
（AES）       （RSA, ECC）   （SHA-256, bcrypt）
   │              │              │
   ▼              ▼              ▼
大容量暗号    鍵交換・署名   改ざん検知・パスワード保管
   │              │              │
   └────► TLS / HTTPS ◄──────────┘
              │
       匿名化 / 差分プライバシー / 同型暗号
            （暗号化＋プライバシー保護）

🔗 隣接手法への橋渡し

暗号化は単独の技術ではなく、 認証 ・完全性検証 ・鍵管理 ・PKI と組み合わせて初めてセキュリティ要件を満たす。 共通鍵 ・公開鍵 ・ハッシュ ・電子署名のどれをどこで使うかを脅威モデルから設計する。

• 上流（前処理・データ整備）: 脅威モデル (情報セキュリティ) / 鍵管理 (公開鍵暗号) / 情報セキュリティ
• 並列（代替・補完手法）: 共通鍵暗号 (公開鍵対比) / 公開鍵暗号 / ハッシュ関数 (電子署名)
• 下流（評価・解釈・応用）: TLS (公開鍵暗号) / デジタル署名 / データ保護

暗号化は「平文を鍵で復号可能な暗号文に変換する」技術で、 上流の脅威モデル (盗聴・改ざん・なりすまし) で要件を決め、 並列の共通鍵 (AES)・公開鍵 (RSA/ECDSA)・ハッシュを組み合わせ、 下流の TLS・ディスク暗号化・電子署名で実装する。

🌳 手法選択フロー

暗号化方式の選択は「脅威モデル (盗聴/改ざん/なりすまし)・鍵管理コスト・性能要求」の 3 軸で決まる。 通信は TLS (公開鍵 + 共通鍵)、 保存は AES、 認証は電子署名と使い分ける。

1. 守りたいのは通信中か、 保存時か
   通信中なら TLS、 保存時ならディスクやカラムの暗号化。 どちらか一方だけでは、 もう一方の経路が空いたままになる。
2. 鍵を誰が持つか
   クラウド事業者が鍵を持つ方式は運用が楽だが、 事業者は復号できる。 事業者にも見せたくないなら、 鍵を自分で管理する。
3. 共通鍵か、 公開鍵か
   大量のデータを速く暗号化するなら共通鍵（AES）。 鍵を安全に渡す、 署名するなら公開鍵。 実際は両者を組み合わせる。
4. 鍵を失ったらどうなるか
   暗号化したデータは、 鍵を失えば復元できない。 バックアップと鍵の保管を別々に設計しておく。

SSDSE-B-2026 の公開データ自体は暗号化対象ではないが、 自治体内で個人情報と突合する DB やバックアップは「保存時 (at rest) と通信時 (in transit) の両方を暗号化」する原則を最初に決める。