目的と復元の条件を分ける

エンコードはデータの表し方を変える操作、暗号化は鍵を使って内容を読めない形へ変える操作、ハッシュは入力から一定の長さの値を計算する操作です。どれも見た目が変わりますが、守る目的が違います。

文字列が複雑に見えるだけで秘密になるとは限りません。たとえばBase64で表したパスワードは誰でも復元できます。住所を後から表示したいなら暗号化と鍵の管理が必要で、パスワードの一致だけを調べたいなら専用ハッシュを使います。

参照:出典 s1 / 出典 s2 / 出典 s3 / 出典 s4

エンコードは秘密なしで復元できる

Base64は、画像や文字のバイト列を、決まった文字の組み合わせで表す方法です。通信や保存の形式へ合わせるために使い、秘密を持たない人も元のバイト列へ戻せます。

URLの中で空白などを%で始まる表記にするパーセントエンコードも、表現を変える操作です。何回変換しても暗号化にはなりません。また、Base64とHTMLの特殊文字を無害な表記にするエスケープは目的が異なり、Base64を使えばXSSを防げるわけでもありません。

説明用の通信例・設定例・擬似コード

原文: hello
Base64: aGVsbG8=

秘密鍵なしで hello へ戻せます。

参照:出典 s1

暗号化は必要な鍵を持つ相手が復号する

暗号化前の内容を平文、暗号化した結果を暗号文、元へ戻す操作を復号と呼びます。たとえば住所を暗号化して保存し、正規の表示処理だけが鍵を使って復号する構成にします。

暗号文を盗んだ相手から内容を守るには、鍵を保護する必要があります。暗号文と一緒に鍵も無条件で読める場所へ置くと、その両方を読んだ攻撃者が復号できます。方式によって必要な追加の値や改ざん検出の条件も違うため、標準的なライブラリーを使います。

参照:出典 s2

ハッシュは元の内容を取り出す保存ではない

ハッシュ関数は、入力から決まった長さの値を計算します。同じ条件の同じ入力からは同じ値を得られ、ファイルの比較などに使えます。暗号学的なハッシュでは、同じ値になる別の入力を見つけにくいことなどが求められます。

ただしハッシュ値は唯一性を数学的に保証する番号ではありません。異なる入力が同じ値になることを衝突と呼びます。また、候補の少ないパスワードなら、候補から計算して一致を探せます。パスワード保存には高速ハッシュをそのまま使わず、専用方式とソルトを使います。

参照:出典 s3 / 出典 s4

ハッシュが一致しても誰が作ったかは分からない

仮定の例として、配布ファイルとハッシュ値を同じ改ざん可能なページへ置くとします。攻撃者がファイルとハッシュの両方を書き換えれば、利用者の照合は成功します。ハッシュの一致だけでは発行元を証明できません。

誰が作ったデータかを検証するには、信頼できる鍵による署名やMACなどを使います。ハッシュの比較で確かめたことと、署名の検証で確かめたことを区別します。

参照:出典 s3 / 出典 s5

見た目ではなく必要な処理から選ぶ

確認問題:忘れたときに原文を表示するため、パスワードをBase64で保存してよいでしょうか。答えは違います。Base64は秘密を守らず、通常の認証で原文の復元は必要ありません。専用のハッシュで照合し、忘れた場合は再設定します。

逆に、後から本文を読まなければならない秘密のメモをハッシュだけで保存すると、本文を復元できません。秘密にしたいか、後から復元するか、改ざんや発行元を検証するかを先に決めます。

参照:出典 s1 / 出典 s2 / 出典 s3 / 出典 s4

出典・確認範囲

  1. [s1] Base64MDN / 確認日 2026-11-03
  2. [s2] SubtleCrypto: encrypt() methodMDN / 確認日 2026-11-03
  3. [s3] SubtleCrypto: digest() methodMDN / 確認日 2026-11-03
  4. [s4] Password Storage Cheat SheetOWASP / 確認日 2026-11-03
  5. [s5] SubtleCrypto: sign() methodMDN / 確認日 2026-11-03
未確認事項・限界

通信例・設定例・被害の例は、仕組みを理解するための仮定です。特定の製品で発生した事件を示すものではありません。ブラウザやサービス固有の設定は、利用する環境の公式資料でも確認してください。