AZ Tools
← ガイド

ハッシュ化 vs 暗号化 vs エンコード: 何が違うのか

ハッシュ化・暗号化・エンコードは互換的に聞こえ、いつも混同されますが、まったく異なる3つの問題を解きます。これらを取り違えると現実のセキュリティバグにつながります — ハッシュ化すべきパスワードを「暗号化」したり、Base64 を秘密のように扱ったり。本ガイドはその境界を明確に引き、常に正しいものを選べるようにします。

エンコード: データを安全に運ぶ

エンコードは、特定の形を期待するシステムを通れるように、データを別の形式へ変換します。Base64、URL のパーセントエンコード、HTML エンティティはすべてエンコードです。鍵も秘密も関与しません: 誰でもエンコードを元に戻せますし、それこそが要点です — 受け手がデコードする必要があるからです。

目的が秘密ではなく互換性のときにエンコードを使います: バイナリを JSON フィールドに入れる、値を URL に安全に載せる、画像を data: URI として埋め込む、など。エンコードをデータの「保護」と考えたなら、それは誤った道具を選んだという警告サインです。

暗号化: 秘密に保ちつつ復元可能に

暗号化は鍵でデータをかき混ぜ、正しい鍵を持つ者だけが元に戻せるようにします。設計上は双方向です — 鍵で暗号化し、鍵(またはその対)で復号します。安全性はアルゴリズムを隠すことではなく、ひとえに鍵を秘密に保つことに依存します。

後で読み戻す必要のある秘密のものを保存・送信するときに暗号化を使います: 転送中のメッセージ(HTTPS)、保存中のファイル、機密の個人データを保持するデータベース列など。決定的な特徴は復元可能性です: 設計上、鍵を持つ者は原本を取り戻せます。

ハッシュ化: 一方向の指紋

ハッシュ化はデータを一方向関数に通し、固定長のダイジェストを生みます。同じ入力は常に同じハッシュを生みますが、鍵はなく戻る道もありません — 出力から入力を導けません。良い暗号学的ハッシュは、同じダイジェストになる2つの入力を見つけることも事実上不可能にします。

復元ではなく検証のためにハッシュ化を使います: ダウンロードが改ざんされていないかの確認、2つのファイルの比較、内容の重複排除など。不可逆だからこそ、原本を取り戻す必要がまったくなく、何かと一致するかだけを確認したいときにハッシュ化が最適です。

三者を結ぶパスワードの例

パスワードはこの三者が衝突し、誤りが最も害をなす場所です。保存するパスワードを暗号化してはいけません。暗号化は可逆で、鍵を盗んだ者がすべてのパスワードを手に入れるからです。代わりにハッシュ化し、漏洩してもパスワードそのものではなくダイジェストだけが露出するようにします。

しかし素の SHA-256 ハッシュは速すぎます: 攻撃者は毎秒数十億回推測できます。そこでパスワードのハッシュ化には、bcrypt、scrypt、Argon2 のように意図的に遅くソルトを加えたアルゴリズムを使います。ソルトは同じパスワードを異なってハッシュ化させ、遅さは大量推測を高くつかせます。ここでエンコードはまったく役割を持ちません。

手早い判断ガイド

どれが必要か迷ったら、何を達成したいかを問い、それに合わせて選びましょう。

  • データを送信・保存し、後で正確な値を非公開で読み戻す必要がある? 暗号化。
  • データが一致するかだけを確認し、復元する必要はない? ハッシュ化 — パスワードなら遅くソルトを加えたハッシュ(bcrypt/Argon2)。
  • テキスト専用または URL 専用の経路でデータを無傷で運ぶ必要がある? エンコード(Base64、URL エンコード)— 秘密のためには決して使わない。
  • メッセージが共有鍵を持つ者から来たと証明する必要がある? ハッシュと秘密鍵を組み合わせた HMAC。

関連ツール