「データを暗号化する」「パスワードをハッシュ化する」「電子ファイルへデジタル署名する」。どれも情報を読みにくい文字列へ変えるため、同じ技術の言い換えに見えるかもしれません。しかし、3つは守るものも、元へ戻せるかどうかも、必要な鍵も違います。
先に要点をまとめると、暗号化は内容を読める相手を制限し、ハッシュはデータが同じかを照合し、デジタル署名はデータを出した主体と改変の有無を検証する仕組みです。実際の通信やソフトウェア配布では、どれか一つで済ませず、複数を組み合わせます。
| 仕組み | 主な目的 | 元データへ戻すか | 鍵の扱い | 単独では分からないこと |
|---|---|---|---|---|
| 暗号化 | 内容を秘密にする | 正しい鍵で復号する | 共通鍵、または公開鍵と秘密鍵 | 送信者が本物か、改変されたか |
| ハッシュ | 同じデータか照合する | 戻す用途ではない | 通常のハッシュ計算には鍵を使わない | 誰が作ったか、内容を秘密にできるか |
| デジタル署名 | 署名者と完全性を検証する | 署名から本文を復元しない | 秘密鍵で署名し、公開鍵で検証する | 本文の機密性 |
この表は役割を理解するための基本形です。実装では、認証付き暗号、鍵付きハッシュ、証明書なども使われます。名前だけで安全性を判断せず、何を守りたいかから選ぶことが重要です。
1. 3つの役割は「秘密・照合・出所」
情報セキュリティでは、目的を分けると技術を選びやすくなります。第三者に内容を読ませたくないなら機密性、途中で書き換えられていないと確かめたいなら完全性、通信相手や作成者を確かめたいなら認証が必要です。
暗号化が主に担うのは機密性です。たとえば端末内のファイルを暗号化すると、保存媒体を持ち出された場合でも、鍵を持たない相手が平文を読める可能性を下げられます。ただし、暗号文を作った相手が本物か、途中で暗号文が改変されていないかは、暗号化という言葉だけでは保証されません。
ハッシュ関数は、入力から一定長のハッシュ値、またはメッセージダイジェストを計算します。入力が同じなら同じ値になり、少し変われば異なる値になる性質を利用して、データの照合や改変検出に使います。ただし、攻撃者が本文とハッシュ値を両方差し替えられる状況では、ハッシュ値を並べておくだけでは防御になりません。
デジタル署名は、秘密鍵を持つ主体がデータに対して署名値を作り、対応する公開鍵を持つ側が検証する仕組みです。検証に成功すれば、署名後にデータが変わっていないことと、対応する秘密鍵で署名されたことを確認できます。ただし、その公開鍵が現実の誰に属するかは、証明書や事前の鍵確認など、別の信頼の仕組みが必要です。
2. 暗号化は正しい鍵で元へ戻す
暗号化では、読める平文を暗号文へ変換し、正しい鍵を使って復号します。元へ戻すことが前提なので、「復元できないようにする」ハッシュとは目的が異なります。
代表的な方式は共通鍵暗号と公開鍵暗号です。共通鍵暗号は、暗号化と復号に同じ秘密の鍵を使います。処理が比較的速く、大量の通信データや保存データを守る用途に向きます。一方、鍵を相手へ安全に渡す方法を別に用意しなければなりません。
NISTのFIPS 197で標準化されたAESは代表的な共通鍵ブロック暗号です。AES-128、AES-192、AES-256は、いずれもデータを128ビットのブロックとして処理し、末尾の数字は鍵のビット長を表します。ただし、「数字が大きい方式を選べば、どの場面でも自動的に安全になる」とは限りません。利用モード、乱数、鍵の生成と保管、実装上の欠陥まで含めて安全性が決まります。
公開鍵暗号では、広く配れる公開鍵と、所有者だけが守る秘密鍵を組み合わせます。公開鍵で暗号化し秘密鍵で復号する用途や、共有秘密を確立する用途があります。大量データをすべて公開鍵暗号で処理するのではなく、通信開始時の鍵共有や認証に公開鍵技術を使い、その後の本文を共通鍵で保護する組み合わせが一般的です。
実際にデータを守るときは、暗号化と改ざん検出を一体化した認証付き暗号がよく使われます。たとえばNIST SP 800-38Dが規定するGCMは、共通鍵ブロック暗号を使う認証付き暗号のモードです。方式名がAESでも、利用モードやノンス（原則として同じ鍵で重複させない値）の扱いを誤れば安全性は損なわれるため、部品を独自に組み立てず、検証済みライブラリの推奨設定を使います。
暗号方式ごとの鍵長は、数字だけを横並びにできません。共通鍵暗号、RSA、楕円曲線暗号では安全性の根拠となる問題と攻撃方法が異なるためです。鍵長だけで製品を順位付けせず、採用する標準、想定する利用期間、鍵管理、更新手段まで確認します。
3. ハッシュは元へ戻さず照合する
暗号学的ハッシュ関数は、長さの異なる入力を一定長の値へ写します。NISTのFIPS 180-4は、メッセージからダイジェストを作り、その後にメッセージが変わったかを検出する用途を説明しています。SHA-256なら出力は256ビットです。
「ハッシュは絶対に逆算できない」という表現は正確ではありません。ハッシュ値から元データを直接復号する鍵はなく、元データを効率よく求めにくいよう設計されています。しかし、候補が「はい／いいえ」や短いパスワードのように少なければ、候補を順に計算し、同じハッシュ値になるものを探せます。
また、入力の種類は出力の種類より多いため、異なる入力が同じハッシュ値になる衝突は数学的に避けられません。安全なハッシュ関数に求められるのは、衝突が存在しないことではなく、実用的な計算量で衝突を見つけるのが困難であることです。用途に適さなくなった古いアルゴリズムを使い続けず、現在の標準と移行方針を確認する必要があります。
ハッシュ関数へ秘密の共有鍵を組み合わせるHMACは、通常のハッシュ値ともデジタル署名とも異なります。RFC 2104では、HMACを共有秘密鍵でメッセージを認証する仕組みとして説明しています。鍵を共有する当事者間で完全性と鍵の所持を確認できますが、検証側も同じ鍵を持つため、第三者へ「特定の一人だけが作った」と示す用途には向きません。
パスワード保存では、一般的なファイル照合と同じようにSHA-256を一度計算するだけでは不十分です。NIST SP 800-63Bは、パスワード、ソルト、コスト係数を入力するパスワードハッシュ方式を使うよう示しています。ソルトは利用者ごとに異なる値を加え、同じパスワードでも保存値が同じになりにくくするものです。コスト係数は計算へ意図的に負荷を加え、大量の候補を試す攻撃の費用を増やします。
ファイル配布ページに載るハッシュ値も、使い方に注意が要ります。信頼できる公式ページから得た値とダウンロード済みファイルの値が一致すれば、転送時の破損や差し替えを発見する材料になります。しかし、偽サイトがファイルとハッシュ値を一緒に置けば、計算上は一致します。配布元の認証まではハッシュ単独で担えません。
4. 署名は秘密鍵の所持と改変の有無を示す
デジタル署名では、署名者が秘密鍵を使って署名値を作り、受け手が公開鍵で検証します。実際の方式では、本文全体をそのまま秘密鍵で処理するのではなく、本文のハッシュ値などから署名値を作ります。本文が1ビットでも変われば検証対象の値も変わるため、元の署名との対応が崩れます。
NISTのFIPS 186-5は、デジタル署名を、データへの不正な変更の検出と署名者の認証に使うものと説明しています。同標準はRSA、ECDSA、EdDSAによる署名生成と検証を規定しています。署名方式とハッシュ方式は組み合わせに条件があるため、独自に部品を選ばず、標準化された構成と検証済みライブラリを使います。
署名を暗号化と混同すると、「秘密鍵で暗号化し、公開鍵で復号する」と説明したくなります。しかし、署名は本文を秘密にする処理ではありません。公開鍵を持つ人が検証できることが目的で、署名付き文書の本文は別途暗号化しない限り読めます。
また、署名が正しくても「現実の本人が自分の意思で署名した」と無条件に証明できるわけではありません。秘密鍵が盗まれた、端末が不正操作された、証明書の本人確認に問題があった、といった可能性は残ります。署名時刻、証明書の有効性、失効情報、秘密鍵の管理、操作記録を含めて判断する必要があります。
ソフトウェア更新や配布ファイルでは、署名を検証することで、信頼する開発元の鍵で署名され、署名後に内容が変わっていないかを確認できます。ハッシュ値だけを載せる方法より出所も検証できますが、利用者側が警告を無視したり、信頼する公開鍵自体を誤ったりすれば保護は弱まります。
5. HTTPSでは3つをどう組み合わせるか
ブラウザでHTTPSのサイトを開くときは、一種類の暗号技術だけが働くわけではありません。IETFの現行TLS 1.3仕様であるRFC 9846は、TLSを盗聴、改ざん、メッセージ偽造を防ぐよう設計されたプロトコルと説明しています。
接続開始時のハンドシェイクでは、クライアントとサーバーが利用する方式を決め、共有する鍵材料を確立します。サーバーは証明書と署名を使い、接続先の認証に必要な情報を示します。ブラウザは証明書の名前、有効性、信頼の連鎖などを検証します。証明書があるだけでサイトの内容や運営者の善良さまで保証されるわけではありません。
ハンドシェイクの記録はハッシュ計算へ取り込まれ、署名やFinishedメッセージの検証に使われます。接続後のアプリケーションデータは、確立した共通鍵で保護します。TLS 1.3のレコード保護はAEAD（追加データ付き認証暗号）を使い、暗号化と改ざん検出を一体として扱います。
流れを単純化すると、次のようになります。
- 証明書と署名を使い、接続先を検証する
- 鍵共有の仕組みで、その接続専用の鍵材料を確立する
- ハッシュを鍵導出やハンドシェイク全体の照合へ使う
- 共通鍵による認証付き暗号で、以後の通信内容を保護する
この組み合わせにより、暗号化だけでは不足する認証と完全性を補います。ただし、利用端末がマルウェアに感染している場合、偽サイトへ自分で情報を入力した場合、サーバー側で情報が漏れた場合などは、通信路のTLSだけでは防げません。
6. よくある誤解を整理する
1つ目は「ハッシュ化も暗号化の一種で、鍵があれば戻せる」という誤解です。暗号化は復号を前提にしますが、ハッシュは照合用の値を作る一方向の処理として設計されます。パスワードを忘れたときにサービスが元の文字列を表示せず、再設定を求める設計は、この違いと関係します。
2つ目は「署名があれば内容を誰にも読まれない」という誤解です。署名が守るのは主に出所と完全性であり、機密性ではありません。秘密にしたい文書は、署名とは別に適切な暗号化が必要です。
3つ目は「ハッシュ値が一致すれば、配布元も本物」という誤解です。ハッシュ値を受け取る経路が攻撃者に置き換えられていれば、偽ファイルと偽ハッシュの組み合わせも一致します。公式サイトのHTTPS、署名、別経路での公開鍵確認など、値の入手元を信頼できるかも確認します。
4つ目は「鍵が長いほど、方式を越えて安全性が高い」という誤解です。鍵長の意味はアルゴリズムによって異なります。鍵の保管が不適切なら、数学的に強い方式でも秘密鍵のコピー一つで破られます。暗号の安全性はアルゴリズム名だけでなく、実装、運用、鍵の更新と破棄を含む仕組み全体で決まります。
5つ目は「量子コンピューターが登場すれば、現在の暗号はすべて同時に使えなくなる」という誤解です。影響は公開鍵暗号、共通鍵暗号、ハッシュで同じではありません。NISTは2024年8月、量子計算機による将来の攻撃へ備えるFIPS 203、204、205を承認しました。FIPS 203は鍵カプセル化、FIPS 204と205はデジタル署名の標準です。移行は製品やプロトコル全体で進める必要があり、独自方式へ急いで置き換えることではありません。
7. 日常で迷わない使い分け
目的から逆引きすると、3つを選びやすくなります。
- 端末内のファイルや通信内容を第三者に読ませたくない: 暗号化
- ダウンロードしたファイルが公式掲載時と同じか確かめたい: 信頼できる経路で得たハッシュ値との照合
- ソフトウェア更新が開発元の鍵で署名され、途中で変わっていないか確かめたい: デジタル署名
- パスワードを元の文字列へ戻さず保存したい: ソルトとコスト係数を使う専用のパスワードハッシュ
- Web通信で盗聴、改ざん、なりすましの危険をまとめて下げたい: 証明書、署名、ハッシュ、認証付き暗号を組み合わせるTLS
利用者としては、アルゴリズムを自作するより、OSやブラウザの更新を続け、証明書警告や署名エラーを無視せず、提供元が公式かを確認する方が重要です。開発者は、実績のある暗号ライブラリと安全な既定値を使い、秘密鍵をソースコードやログへ残さず、鍵の漏えいを前提とした交換手順を設けます。
記事や公開データの品質管理でも、ハッシュは「同じファイルか」を機械的に検査する部品として役立ちます。ただし、正しい内容かどうかは検査できません。形式の検査と人による事実確認を分ける考え方は、AI記事に機械の門番を付ける方法でも解説しています。
8. よくある質問
暗号化したパスワードを保存すれば安全ですか？
パスワード認証では、必要時に元の文字列へ戻せる暗号化より、ソルトとコスト係数を使う専用のパスワードハッシュで照合する設計が基本です。サービスが元のパスワードを取り出せる設計では、復号鍵が漏れたときの影響も考える必要があります。
SHA-256のハッシュ値が一致すれば、ファイルは安全ですか？
分かるのは、比較した範囲でファイルが同じである可能性が高いことです。ファイルの内容が無害か、配布元が本物かまでは判定できません。ハッシュ値そのものを公式サイトなど信頼できる経路から得ることも必要です。
HMACとデジタル署名は何が違いますか？
HMACは作成側と検証側が同じ秘密鍵を共有します。デジタル署名は秘密鍵で署名し、公開鍵で検証するため、検証者へ秘密鍵を渡さずに済みます。少人数のシステム間認証と、不特定多数が検証するソフトウェア配布では、適した仕組みが異なります。
HTTPSの鍵マークがあれば、そのサイトは安全ですか？
鍵マークは、主にブラウザと接続先の間でTLSが成立していることを示します。サイトの運営者が信頼できるか、掲載内容が正しいか、入力後のデータ管理が適切かまでは保証しません。ドメイン名や警告表示も併せて確認します。
9. 関連記事
暗号化、ハッシュ、署名は競合する選択肢ではなく、異なる失敗を防ぐ部品です。「読ませない」「変化を見つける」「誰の鍵によるものか確かめる」のどれが必要かを分け、必要なら組み合わせる。それが、用語の印象ではなく目的からセキュリティを考える出発点です。
一次情報メモ（確認日: 2026-07-23）
- NIST「FIPS 197, Advanced Encryption Standard (AES)」: AESが機密性を提供するブロック暗号の標準であり、AES-128、AES-192、AES-256の鍵長と128ビットのブロック長を確認。https://csrc.nist.gov/pubs/fips/197/final
- NIST「SP 800-38D, Recommendation for Block Cipher Modes of Operation: GCM and GMAC」: GCMが追加データ付き認証暗号、GMACが暗号化しないデータのメッセージ認証コードであることを確認。https://csrc.nist.gov/pubs/sp/800/38/d/final
- NIST「FIPS 180-4, Secure Hash Standard (SHS)」: ハッシュがメッセージのダイジェストを生成し、生成後の変更検出に使われることを確認。https://csrc.nist.gov/pubs/fips/180-4/upd1/final
- IETF「RFC 2104, HMAC: Keyed-Hashing for Message Authentication」: HMACが暗号学的ハッシュ関数と共有秘密鍵を組み合わせるメッセージ認証の仕組みであることを確認。https://www.rfc-editor.org/info/rfc2104
- NIST「FIPS 186-5, Digital Signature Standard (DSS)」: デジタル署名の目的が不正変更の検出と署名者の認証であり、RSA、ECDSA、EdDSAを規定することを確認。https://csrc.nist.gov/pubs/fips/186-5/final
- IETF「RFC 9846, The Transport Layer Security (TLS) Protocol Version 1.3」: 2026年7月発行の現行TLS 1.3仕様、ハンドシェイク、署名、トランスクリプトハッシュ、AEADによる通信保護を確認。https://www.rfc-editor.org/rfc/rfc9846.html
- NIST「SP 800-63B, Digital Identity Guidelines: Authentication and Authenticator Management」: パスワード保存で、パスワード、ソルト、コスト係数を入力するパスワードハッシュ方式を使う指針を確認。https://pages.nist.gov/800-63-4/sp800-63b.html
- NIST「Announcing Approval of Three Federal Information Processing Standards for Post-Quantum Cryptography」: FIPS 203が鍵カプセル化、FIPS 204と205がデジタル署名の耐量子標準であることを確認。https://www.nist.gov/news-events/news/2024/08/announcing-approval-three-federal-information-processing-standards-fips