暗号学

1. 暗号学の概要と目的

暗号学（Cryptology）は、情報を第三者に読み取られない形に変換する技術と、その安全性を数学的に評価する手法を扱う学問分野です。

Webサイトの通信がHTTPSで保護されていること、パスワードがそのまま保存されていないこと、ソフトウェアの更新ファイルが改ざんされていないと確認できること。これらはすべて暗号学の成果の上に成り立っています。

この章では、暗号学がどのようなものなのか、また、なぜ知っておく必要があるのかを確認します。

暗号学とは？

暗号学とは、情報を保護するための技術体系と、その強度を評価する理論を扱う分野です。大きく、安全な方式を設計する「暗号作成（Cryptography）」と、その方式を破る手法を研究する「暗号解読（Cryptanalysis）」の二つに分かれます。

暗号学が守ろうとする性質は、主に次の4つです。

機密性（Confidentiality）： 許可された者以外が内容を読めないこと。
完全性（Integrity）： データが途中で改ざんされていないこと。
認証（Authentication）： 通信相手やデータの作成者が本人であること。
否認防止（Non-repudiation）： 作成や送信の事実を後から否定できないこと。

例えば、「暗号化されているから安全」という表現がよく使われますが、これは機密性だけを指しています。

暗号化のみ：内容は読めないが、改ざんされても気づけない

一方、現在の実装では次のように、複数の性質を同時に満たす方式が用いられます。

認証付き暗号（AEAD）：内容を読めないうえに、改ざんがあれば検知できる

このように、「何を守りたいのか」を定めて適切な方式を選ぶ点が暗号学の実践における要点です。

なお、暗号学の安全性は「アルゴリズムを秘密にすること」ではなく「鍵を秘密にすること」に依存させるべきである、という原則があります。これをケルクホフスの原理と呼びます。広く公開され、長年にわたり多くの研究者の攻撃に耐えた方式こそが信頼できる、という考え方です。

暗号学はどのような場面で登場するのか？

暗号学は、学問としてだけでなく、日常的なシステム開発や運用のあらゆる場面で実装として登場します。

例えば、次のような場面が代表的な利用例です。

通信の保護： HTTPS（TLS）による、ブラウザとサーバー間の通信の暗号化。
パスワードの保管： 利用者のパスワードを、復元できない形に変換して保存する。
データの保護： データベースやディスク、バックアップファイルの暗号化。
真正性の確認： 電子署名による、ソフトウェアや文書の改ざん検知と発行元の確認。
トークンの検証： APIの認証や、JWTなどの署名付きトークンの正当性確認。

Web開発者やインフラ担当者にとって、暗号学はアルゴリズムを自ら実装するためではなく、「既存の方式を正しく選び、正しく使う」ために必要な知識です。

2. 暗号学の仕組み・規格・主な特徴

暗号学の実装は、いくつかの基本部品（プリミティブ）を組み合わせて構成されます。

部品にはそれぞれ役割が決まっており、組み合わせ方を誤ると、個々の部品が安全でも全体としては破られてしまいます。

ここでは、代表的な方式の違いや、実際の構成例を確認します。

共通鍵暗号と公開鍵暗号の違いと特徴

暗号方式は、鍵の扱い方によって大きく2種類に分けられます。

共通鍵暗号（対称鍵暗号）： 暗号化と復号に同じ鍵を使う方式。処理が高速で、大量のデータの暗号化に適しています。代表的な方式は AES や ChaCha20 です。ただし、鍵を相手へ安全に渡す手段が別途必要になります。
公開鍵暗号（非対称鍵暗号）： 対になる2つの鍵を使い、一方（公開鍵）は誰に渡しても構わず、もう一方（秘密鍵）だけを手元で保持する方式。鍵の受け渡し問題を解決できる一方、処理は低速です。

公開鍵を用いる方式は、担う役割によって次の3種類に分かれます。混同されやすい部分なので、整理しておくと理解しやすくなります。

暗号化： 公開鍵で暗号化し、秘密鍵で復号する。RSA-OAEP などが該当します。
電子署名： 秘密鍵で署名を作り、公開鍵で検証する。RSA-PSS・ECDSA・Ed25519 などが該当します。
鍵交換（鍵合意）： 互いの公開鍵をやり取りし、双方が同じ共有値を計算する。ECDH やその実装である X25519 が該当します。

楕円曲線暗号のうち ECDSA と Ed25519 は署名用、X25519 は鍵交換用であり、データそのものを暗号化する機能は持ちません。「公開鍵暗号」という言葉は、これら全体を指す場合と、狭く暗号化方式だけを指す場合があります。

実際のシステムでは、共通鍵暗号と公開鍵を用いる方式を組み合わせたハイブリッド構成が使われます。TLS 1.3であれば、鍵交換（X25519 などのECDHE）で共通鍵の素となる値を共有し、サーバー証明書の電子署名で接続先の正当性を確認したうえで、以降の通信を高速な共通鍵暗号で保護します。かつて使われていた「公開鍵暗号で共通鍵そのものを暗号化して送る」方式（RSA鍵転送）は、TLS 1.3で廃止されました。

このほか、暗号学には次のような基本部品があります。

ハッシュ関数： 任意の長さの入力から固定長の値を求める一方向の関数。SHA-256 や SHA-3 が現役です。MD5 と SHA-1 は衝突（異なる入力から同じ値を作ること）が現実的な計算量で可能になっており、使用すべきではありません。
メッセージ認証コード（MAC）： 共通鍵を使い、データが改ざんされていないことを確認する仕組み。HMAC が代表的です。
鍵導出関数（KDF）： 既存の鍵素材から、用途ごとの鍵を導く関数。HKDF が代表的です。
パスワードハッシュ関数： パスワードの保管に用いる、意図的に計算を重くした関数。Argon2id・bcrypt・scrypt が該当します。総当たりを遅くすることが目的のため、高速な SHA-256 では代替できません。
乱数生成器： 鍵やノンスを生成する基盤。暗号用途では暗号論的に安全な生成器（CSPRNG）が必須です。

処理の流れを、HTTPS通信を例に追うと次のようになります。

ブラウザとサーバーが、利用する暗号方式（暗号スイート）を決める。
鍵交換の方式（ECDHE など）によって、共通鍵の素となる値を安全に共有する。
サーバー証明書の電子署名を検証し、接続先が正当であることを確認する。
共有した値から共通鍵を導出し、以降のデータを認証付き暗号で保護する。

この流れのどこかで古い方式が使われていると、全体の安全性がその部分に引きずられます。

暗号方式の選択と記述

実務では、アルゴリズムを実装するのではなく、ライブラリが提供する方式を適切に選択します。

例えば、次のような記述になります。

【記述・構造の具体例】

用途ごとに適切な方式を選択する例です。

# データの暗号化：認証付き暗号（AES-GCM）を使用する
from cryptography.hazmat.primitives.ciphers.aead import AESGCM
import os

key = AESGCM.generate_key(bit_length=256)
nonce = os.urandom(12)              # 毎回新しい値を生成する
ct = AESGCM(key).encrypt(nonce, b"secret data", None)

# パスワードの保管：専用のパスワードハッシュ関数を使用する
from argon2 import PasswordHasher

ph = PasswordHasher()
stored = ph.hash("user-password")   # 保存するのはこの値
ph.verify(stored, "user-password")  # 照合はライブラリの関数で行う

# データの同一性確認：ハッシュ関数を使用する
import hashlib

digest = hashlib.sha256(b"file contents").hexdigest()

このように、「内容を秘匿したいのか」「本人のパスワードか確認したいのか」「同じデータか確認したいのか」という目的に応じて、使う部品が変わります。

なお、日本国内では、CRYPTRECが公開する暗号リストが方式選択の参考になります。安全性と実装実績が評価された方式が整理されており、政府調達の基準にもなっています。

3. 暗号学が使われる理由・メリットと活用シーン

暗号学が必要とされる理由は、インターネットが「通信経路を信頼できない」前提で成り立っているからです。

経路上の第三者がデータを覗いたり書き換えたりできる環境でも、暗号技術があれば内容の秘匿と改ざんの検知が可能になります。

暗号技術を使うメリット

暗号技術を用いない場合、通信経路やサーバーに侵入された時点で、情報はそのまま読み取られてしまいます。

適切な暗号技術を使用することで、次のようなメリットが生まれます。

盗聴への耐性： 通信を傍受されても、内容を読み取られない。
改ざんの検知： データが書き換えられた場合に、受け取り側で気づける。
なりすましの防止： 証明書や署名によって、通信相手が正当であることを確認できる。
漏えい時の被害軽減： データベースが流出しても、パスワードが適切に保管されていれば、そのまま悪用されにくい。
法令・基準への適合： 個人情報保護やPCI DSSなど、各種基準が求める保護水準を満たせる。

ただし、暗号技術は「使えば安全になる」ものではありません。鍵が漏れれば保護は無効になり、古い方式を使っていれば破られます。運用とセットで初めて効果を持ちます。

Web開発やシステム運用で活用する

実際の開発・運用では、以下のような場面で活用されます。

TLSによる通信保護： Webサイト、API、メール送受信、データベース接続の暗号化。
パスワードの保管： 利用者の認証情報を、復元不可能な形で保存する。
保存データの暗号化： ディスク全体の暗号化、データベースの特定列の暗号化、バックアップの保護。
署名による検証： ソフトウェア配布物の署名、JWTの署名検証、Webhookの正当性確認。
秘密情報の管理： APIキーや接続情報を、暗号化した状態で保管・配布する。

このように、データが「動くとき」と「保存されているとき」の両方で保護が必要になります。

暗号設定の確認方法

自分のサーバーやアプリケーションがどの方式を使っているかは、コマンドで確認できます。

# TLSの接続状況と、合意された暗号スイートを確認する
openssl s_client -connect example.com:443 -brief

# 証明書の署名アルゴリズムと鍵の長さを確認する
openssl s_client -connect example.com:443 2>/dev/null \
  | openssl x509 -noout -text | grep -E "Signature Algorithm|Public-Key"

# 対応している暗号スイートを一覧で調べる
nmap --script ssl-enum-ciphers -p 443 example.com

確認すべきは、TLS 1.2以上が使われていること、SHA-1 による署名や短い鍵長が残っていないこと、そして古い方式（RC4・3DES・TLS 1.0/1.1）が無効化されていることです。

アプリケーション側のコードについては、md5・sha1・ECB・PBKDF2 の反復回数といったキーワードをプロジェクト全体から検索し、古い方式が残っていないか点検するとよいでしょう。

4. 暗号学の導入・運用時の注意点と課題

暗号技術は、方式そのものが破られるケースよりも、使い方を誤って破られるケースが圧倒的に多いという特徴があります。

正しいアルゴリズムを選んでいても、組み合わせ方や鍵の扱いを誤れば保護は成立しません。

ここでは、実務上注意すべきポイントを説明します。

よくあるミス・設定ミス

最も重大な問題の一つが、独自の暗号方式やプロトコルを自分で設計・実装してしまうことです。

暗号方式の安全性は、公開され、長期間にわたって多くの専門家の攻撃に耐えることで初めて確かめられます。社内で考案した方式は、その検証を一切受けていません。暗号の実装は、実績のあるライブラリに委ねるのが原則です。

また、次のようなミスも頻出します。

パスワードを通常のハッシュ関数で保管： SHA-256 は高速なため、総当たりに耐えられません。パスワードには Argon2id・bcrypt・scrypt を使用します。
ソルトの未使用： ソルトがないと、事前計算された一覧（レインボーテーブル）との照合で容易に判明します。なお Argon2 や bcrypt はソルトを自動で生成・付与するため、専用の関数を使っていればこの問題は起きません。
鍵のソースコードへの埋め込み： リポジトリに鍵を書き込むと、履歴に残り続けます。コミット後に削除しても履歴から取得されます。
ECBモードの使用： ブロック単位で同じ平文が同じ暗号文になるため、データの構造が透けて見えます。
IVやノンスの再利用： 方式によっては、再利用だけで内容の復元や偽造が可能になります。
文字列比較による検証： 署名やトークンの照合で先頭から順に比較すると、処理時間の差から正解を推測される恐れがあります。専用の定数時間比較関数を使用します。

運用・セキュリティ上の注意点

暗号モードの選択を誤ると、暗号化しているにもかかわらず内容が推測できてしまいます。

【よくある失敗・注意点の例】

ブロック暗号のモードに ECB を選んでしまっている例です。

危険な実装

# ECBモードは同じ平文ブロックが同じ暗号文ブロックになる
from cryptography.hazmat.primitives.ciphers import Cipher, algorithms, modes

cipher = Cipher(algorithms.AES(key), modes.ECB())

安全な実装

# 認証付き暗号（GCM）を使い、ノンスは毎回生成する
from cryptography.hazmat.primitives.ciphers.aead import AESGCM
import os

nonce = os.urandom(12)
ct = AESGCM(key).encrypt(nonce, plaintext, None)

この例では、ECB モードが平文のブロックごとに独立して暗号化を行うため、同じ内容のブロックが常に同じ暗号文になります。画像を暗号化すると元の輪郭が判別できてしまうことが古くから知られており、データベースの列を暗号化した場合も、同じ値を持つ行を特定できてしまいます。

さらに、ECB や CBC には改ざんを検知する仕組みがありません。認証機能を持つ GCM などの認証付き暗号（AEAD）を選ぶことで、秘匿と改ざん検知を同時に満たせます。

そのほか、運用面では次の点にも注意が必要です。

鍵の管理： 暗号技術の安全性は鍵の管理に集約されます。保管場所、アクセス権限、定期的な更新、漏えい時の失効手順をあらかじめ定めておく必要があります。
方式の寿命： 安全とされる方式は時代とともに変わります。MD5 も SHA-1 も、かつては標準的に使われていました。利用中の方式を定期的に見直す運用が欠かせません。
鍵の長さ： RSA は2048ビット以上（長期的な保護には3072ビット以上）、楕円曲線暗号は256ビット以上が目安です。
量子計算機への備え： 将来的に大規模な量子計算機が実現すると、RSA や楕円曲線暗号は破られるとされています。これに備えた耐量子計算機暗号が2024年にNISTで標準化され、TLSでは従来方式との併用による移行が始まっています。影響を受けるのは主に公開鍵を用いる方式で、AES などの共通鍵暗号やハッシュ関数は、鍵長や出力長に余裕を持たせれば引き続き利用できるとされています。なお、長期間秘匿したいデータについては、現在の通信を保存して後から解読される可能性も考慮に入れてください。
証明書の有効期限： 期限切れによる障害は頻繁に起こります。自動更新と監視を組み合わせて管理します。

安全に利用するための対策

暗号技術を適切に運用するためには、以下の対策が有効です。

暗号アルゴリズムやプロトコルを自分で実装せず、実績のあるライブラリを利用する。
データの暗号化には認証付き暗号（AEAD）を選び、秘匿と改ざん検知を同時に確保する。
パスワードの保管には専用のパスワードハッシュ関数を使用し、通常のハッシュ関数で代替しない。
鍵やノンスの生成には、暗号論的に安全な乱数生成器を使用する。
鍵はソースコードに書かず、環境変数や専用の鍵管理サービスで扱う。
TLSの設定を定期的に点検し、古いプロトコルや暗号スイートを無効化する。
利用している方式を定期的に棚卸しし、推奨から外れたものを置き換える。

特に、暗号技術は「導入して終わり」にできない分野です。方式の安全性が時間とともに低下することを前提に、見直しの仕組みを運用へ組み込んでおくことが重要です。

5. まとめと関連ツールのご案内

ここまで解説した暗号学について、重要なポイントを振り返ります。

暗号学 は、情報を保護する技術と、その安全性を評価する理論を扱う分野である。
守るべき性質は、機密性・完全性・認証・否認防止の4つに整理される。
安全性は鍵の秘密性に依存させるべきであり、アルゴリズムの秘匿に頼ってはならない（ケルクホフスの原理）。
共通鍵暗号と公開鍵を用いる方式は役割が異なり、実際のシステムでは組み合わせて使われる。
公開鍵を用いる方式は、暗号化・電子署名・鍵交換の3つの役割に分かれ、方式ごとに担う役割が決まっている。
ハッシュ化・エンコード・暗号化はそれぞれ別の概念であり、混同すると誤った実装につながる。
パスワードの保管には通常のハッシュ関数ではなく、専用のパスワードハッシュ関数を使用する。
暗号技術は方式そのものより使い方で破られることが多く、鍵管理と定期的な見直しが不可欠である。

【お役立ちツールのご案内】

ここまで解説した暗号技術の基盤となる「推測できない値」を、実際に手元で生成したい場合は、当サイトの セキュアパスワード生成ツール をぜひご活用ください。

暗号論的に安全な乱数をもとに、文字種や長さを指定してパスワードを生成できます。各種アカウントのパスワードや、暗号化ファイルのパスフレーズを用意する際にお役立てください。

暗号学