はじめに
HTTPS、SSH、JWTなど、日々使う仕組みの安全性は暗号技術が支えている。
一見すると複雑だが、その正体はいくつかの基本部品の組み合わせである。
本記事はシリーズの第1回として、暗号技術の土台となる次の部品を解説する。
- 共通鍵暗号と公開鍵暗号
- 一方向性関数とトラップドア関数（
RSAや楕円曲線暗号の数学的な核心） - ハッシュ関数
- デジタル署名
シリーズ全体では、公開鍵の用途を「署名」「暗号化」「鍵交換」の3つに整理する視点で進める。
- 第1回（本記事）: 暗号の基礎部品
- 第2回: 鍵交換とPKI
- 第3回: 暗号技術の応用：TLS・JWT・SSH
- 実践編: 公開鍵の3つの使い道
なお、暗号化やハッシュ化を他のデータ変換と並べて比較した整理はデータ変換方式の比較にまとめている。本記事はその仕組みを掘り下げる位置づけである。
正確性を確認できるよう、各節の根拠となる一次ソースを末尾に示す。
共通鍵暗号と公開鍵暗号
暗号方式は、鍵の使い方によって共通鍵暗号と公開鍵暗号の2つに大別される。
共通鍵暗号（対称鍵暗号）
暗号化と復号に同じ鍵を使う方式である。代表例はAESである。
平文 --[鍵Kで暗号化]--> 暗号文 --[同じ鍵Kで復号]--> 平文
計算が高速で、大量のデータを暗号化する用途に向く。
一方で、通信相手とどうやって同じ鍵を安全に共有するかという「鍵配送問題」が課題となる。
公開鍵暗号（非対称鍵暗号）
公開鍵と秘密鍵という、対になる2つの鍵を使う方式である。代表例はRSAや楕円曲線暗号である。
公開鍵は誰に渡してもよく、秘密鍵は本人だけが秘密に保つ。
片方の鍵で処理したものはもう片方の鍵でしか元に戻せない、という非対称性が核心である。
公開鍵で暗号化 --> 秘密鍵でしか復号できない（機密性）
秘密鍵で署名 --> 公開鍵で検証できる（真正性）
計算は共通鍵暗号より遅いため、大量データの暗号化には向かない。
使い分け（ハイブリッド）
実際の通信では、両者を組み合わせるのが定石である。
まず公開鍵暗号で相手を認証して共通鍵を安全に共有し、以降は共通鍵暗号で本体を高速にやり取りする。
| 観点 | 共通鍵暗号 | 公開鍵暗号 |
|---|---|---|
| 鍵の数 | 1つ（共有） | 2つ（公開鍵・秘密鍵） |
| 速度 | 速い | 遅い |
| 主な課題 | 鍵配送 | 計算コスト・鍵の真正性 |
| 代表例 | AES |
RSA・楕円曲線暗号 |
一方向性関数とトラップドア関数
公開鍵暗号の安全性は、「計算は簡単だが逆計算は難しい」という数学的な性質に支えられている。
一方向性関数
順方向の計算は容易でも、逆方向の計算が現実的な時間では困難な関数を一方向性関数と呼ぶ。
たとえば2つの素数を掛けるのは一瞬だが、その積から元の素数を求める素因数分解は、桁が大きくなると極めて難しい。
トラップドア関数
一方向性関数のうち、ある秘密の情報（トラップドア）を知っていれば逆計算ができるものをトラップドア関数と呼ぶ。
この秘密の情報が秘密鍵にあたる。公開鍵暗号はトラップドア関数の上に成り立っている。
RSA：素因数分解の困難性
RSAは、大きな合成数の素因数分解が難しいことを安全性の根拠とする。
n = p * q (p, q は大きな素数)
公開鍵: (n, e) 秘密鍵: d
暗号化・検証: c = m^e mod n
復号・署名: m = c^d mod n
nは公開されるが、そこからpとqを割り出せなければ秘密鍵dは求められない。
楕円曲線暗号：離散対数の困難性
楕円曲線暗号（ECC）は、楕円曲線上の離散対数問題の困難性を根拠とする。
Q = k * G (G はベースポイント、k は秘密のスカラー)
GとQが分かっても、kを逆算するのは難しい。
同じ安全性をより短い鍵長で実現できるため、RSAより鍵が小さくて済む利点がある。
「困難」の意味
ここでの「困難」は、現在知られているアルゴリズムと計算機では現実的な時間で解けない、という意味である。
数学的に絶対不可能と証明されたわけではない。将来、量子計算機が実用化されればRSAやECCは破られうる。そのため耐量子暗号の標準化が進んでいる。
ハッシュ関数
ハッシュ関数は、任意の長さの入力を固定長の出力（ハッシュ値）に変換する一方向の関数である。
"hello" --> 2cf24dba5fb0a30e... (SHA-256, 256ビット)
"hellp" --> 7c8e8b58a3b2... (1文字違うだけで全く別の値)
主な性質は次のとおりである。
- 決定性: 同じ入力からは必ず同じ出力が得られる
- 一方向性: ハッシュ値から元の入力を復元できない
- 衝突困難性: 同じハッシュ値になる別の入力を見つけにくい
- 雪崩効果: 入力がわずかに変わると出力が大きく変わる
代表例はSHA-256（SHA-2系）やSHA-3である。MD5やSHA-1は衝突が見つかっており、署名用途で使うべきではない。
用途は、データの完全性検証、デジタル署名の前処理、パスワード保存などである。パスワード保存ではソルトとストレッチを併用する。
ハッシュ化は鍵を使わず元にも戻せないため、暗号化とは別物である。この違いはデータ変換方式の比較で整理している。
デジタル署名
デジタル署名は、「誰が作ったか（真正性）」と「改ざんされていないか（完全性）」を保証する仕組みである。
署名はハッシュにかける
署名はデータそのものではなく、データのハッシュに対して行う。
固定長のハッシュを対象にすることで、大きなデータでも効率よく署名でき、安全性も高まる。
署名 (sign):
hash = H(message)
signature = Sign(秘密鍵, hash)
検証 (verify):
Verify(公開鍵, message, signature) -> true / false
署名は秘密鍵で作り、検証は公開鍵で行う。
秘密鍵を持つ本人だけが署名を作れて、公開鍵を持つ誰もが検証できる。
暗号化との対比
署名と暗号化は、鍵を使う向きがちょうど逆になっている。
- 暗号化: 公開鍵で暗号化し、秘密鍵で復号する（機密性）
- 署名: 秘密鍵で署名し、公開鍵で検証する（真正性）
代表的な方式は、RSA署名（RSASSA-PSSなど）、ECDSA、EdDSAである。
公開鍵が支える3つの用途
ここまでの部品を踏まえると、公開鍵（鍵ペア）の用途は次の3つに整理できる。
- ①署名: 秘密鍵で署名し、公開鍵で検証する。認証・真正性・改ざん検知に使う
- ②暗号化: 公開鍵で暗号化し、秘密鍵で復号する。機密性に使う（①の鏡像）
- ③鍵交換: 共通鍵を安全に共有する。第2回で詳しく扱う
世の中の暗号応用は、ほぼこの3つの組み合わせで説明できる。この視点は第3回の応用編で効いてくる。
まとめ
本記事では暗号技術の基礎部品を整理した。
| 部品 | 役割 | 代表例 |
|---|---|---|
| 共通鍵暗号 | 高速な暗号化 | AES |
| 公開鍵暗号 | 認証・鍵共有 | RSA・ECC |
| 一方向性／トラップドア関数 | 公開鍵暗号の数学的土台 | 素因数分解・離散対数 |
| ハッシュ関数 | 完全性・署名の前処理 | SHA-256・SHA-3 |
| デジタル署名 | 真正性・完全性 | ECDSA・EdDSA |
次回は、共通鍵を安全に共有する「鍵交換」と、公開鍵の正しさを保証する「PKI」を扱う。
参考
- Rivest, Shamir, Adleman. "A Method for Obtaining Digital Signatures and Public-Key Cryptosystems". Communications of the ACM 21(2), 1978. https://doi.org/10.1145/359340.359342
- RFC 8017: PKCS #1: RSA Cryptography Specifications Version 2.2. https://www.rfc-editor.org/rfc/rfc8017
- NIST SP 800-186. Recommendations for Discrete Logarithm-Based Cryptography. https://csrc.nist.gov/pubs/sp/800/186/final
- FIPS 180-4: Secure Hash Standard (SHS). https://csrc.nist.gov/pubs/fips/180-4/upd1/final
- FIPS 202: SHA-3 Standard: Permutation-Based Hash and Extendable-Output Functions. https://csrc.nist.gov/pubs/fips/202/final
- FIPS 197: Advanced Encryption Standard (AES). https://csrc.nist.gov/pubs/fips/197/final
- FIPS 186-5: Digital Signature Standard (DSS). https://csrc.nist.gov/pubs/fips/186/5/final
- RFC 8032: Edwards-Curve Digital Signature Algorithm (EdDSA). https://www.rfc-editor.org/rfc/rfc8032
