【情報セキュリティマネジメント】ハッシュ関数・SHA-256・MACの違い、分かれ目は「鍵を使うか」｜メッセージダイジェスト・メッセージ認証・完全性・否認防止

ハッシュ関数、MAC、デジタル署名は、いずれも「データが変わっていないか」「誰が作成・送信したのか」を確認する場面で使われます。

しかし、使う鍵と、確認できる範囲は異なります。

見分けるポイントは、次の三つです。

1. 鍵を使うか
2. 共有秘密鍵か、署名鍵・検証鍵の組か
3. 誰に対して、何を証明したいか

鍵を使わないハッシュ値は、信頼できる基準値との比較によって内容の変化を確認します。共有秘密鍵を使うMACは、完全性に加え、その鍵を持つ主体のいずれかによって生成されたことを確認できます。

一方、共有秘密鍵を持つ者は双方ともMACを生成できるため、特定の一人が生成したことを第三者へ証明する用途や、否認防止には適していません。

この記事では、ハッシュ関数、SHA-256、メッセージダイジェスト、MAC、HMACの違いを中心に整理します。

読み終えるころには、事例に出てくる仕組みを鍵から見分け、その仕組みで何が確認できて何が確認できないのかを自分で判断できるようになります。

先に結論：鍵の有無と種類で、確認できることが変わる

試験では、「完全性」という語だけで判断せず、鍵を使うか、誰がその鍵を持つか、第三者による検証が必要かを確認します。

1．ハッシュ関数：任意長の入力から固定長の値を生成する

ハッシュ関数は、任意の長さの入力データから、一定の長さのハッシュ値を生成する処理です。

ハッシュ値は、メッセージダイジェスト、ダイジェスト、フィンガープリントなどと呼ばれる場合があります。

代表例であるSHA-256（Secure Hash Algorithm）は、短い文字列でも大きなファイルでも、256ビットのハッシュ値を生成します。

ハッシュ関数の基本的な動作と、暗号学的ハッシュ関数に求められる安全性を分けて確認します。

なお、原像計算困難性、第二原像計算困難性、衝突耐性、フィンガープリントという用語名自体は、SGシラバスVer.4.1の用語例には明示されていません。本記事では、ハッシュ関数の性質を理解するための関連知識として扱います。

同じ入力から同じ出力が得られる

同じハッシュ関数へ同じデータを入力すれば、同じハッシュ値が得られます。

この性質があるため、送信前後又は配布前後の値を比較できます。

一方向性・原像計算困難性

ハッシュ値だけから、元の入力データを現実的な時間で求めることが難しい性質です。

「絶対に数学的に戻せない」という意味ではなく、適切な暗号学的ハッシュ関数では、元データを効率的に求める方法が知られていないという意味です。

第二原像計算困難性

ある入力データと同じハッシュ値になる別の入力を、現実的な時間で見つけることが難しい性質です。

衝突耐性

同じハッシュ値になる異なる二つの入力を、現実的な時間で見つけることが難しい性質です。

入力候補は非常に多く、出力長は有限なので、数学的には同じハッシュ値になる組合せが存在します。

安全なハッシュ関数で重要なのは、「衝突が絶対に存在しない」ことではなく、「攻撃に利用できる衝突を現実的な計算量で見つけにくい」ことです。

入力が少し変わると出力が大きく変わる

入力の一部を変更すると、通常、ハッシュ値は大きく異なる値になります。

この特徴により、データの小さな変更も比較によって発見しやすくなります。ただし、これは原像計算困難性・第二原像計算困難性・衝突耐性とは別の観点です。

2．ハッシュ関数は暗号化ではない

暗号化は、鍵を使って平文を暗号文へ変換し、対応する鍵による復号を前提とします。

一方、ハッシュ関数は、入力からハッシュ値を生成する一方向の処理です。

ハッシュ関数には、暗号文を元の平文へ戻すための「復号鍵」はありません。

したがって、次の説明は誤りです。

• ハッシュ値を復号して元の文書を読む
• 正しい復号鍵を使ってハッシュ値を元へ戻す
• 共通鍵をハッシュ化して送信し、受信者が元の鍵を復元する
• 保存されたパスワードハッシュを復号してパスワードを取り出す

推測攻撃と復号を区別する

ハッシュ値から元の入力を直接復号できなくても、攻撃者が候補を次々にハッシュ化し、保存値と一致するものを探すことはできます。

例えば、保存されたパスワードハッシュに対して、

1. よく使われるパスワード候補を用意する
2. 候補からハッシュ値を計算する
3. 保存された値と比較する
4. 一致する候補を探す

という攻撃が考えられます。

これはハッシュ値の復号ではなく、候補を推測して一致を探す攻撃です。

3．ハッシュ値でファイルの完全性を確認する

ファイルが配布後に変化していないか確認する基本手順は、次のとおりです。

1. 配布元が真正なファイルからハッシュ値を計算する
2. 配布元が基準となるハッシュ値を公表する
3. 利用者が取得したファイルから同じ方式でハッシュ値を計算する
4. 二つの値を比較する

値が一致しない場合

ハッシュ値が一致しない場合、配布元が基準値を計算したファイルと、利用者が取得したファイルは同一ではありません。

• 通信・保存中の破損
• 改ざん
• 別バージョンの取得
• 計算方式の取り違え

などを確認します。

値が一致する場合

安全性が確認されたハッシュ関数を使用し、基準値を信頼できる経路から入手していれば、取得したファイルが基準となるファイルから変化していないと判断する有力な材料になります。

ただし、ハッシュ値が一致したという事実だけで、次の全てを証明できるわけではありません。

• ファイル作成者が誰か
• ファイルの内容が安全か
• マルウェアが含まれていないか
• 公表者が正規の配布元か
• ファイルが業務上適切か

4．基準となるハッシュ値も信頼できる必要がある

攻撃者が配布サイトを侵害し、

• 不正なファイル
• その不正ファイルから計算したハッシュ値

を同時に掲載した場合、利用者が計算した値と掲載値は一致します。

この場合、ハッシュ計算自体は正しくても、比較の基準が攻撃者によって置き換えられています。

そのため、基準ハッシュ値そのものの真正性も確認します。例えば、次のような方法があります。

• 検証済みのデジタル署名と結び付いたリリース情報を利用する
• 配布ファイルとは独立した、信頼できる経路で基準値を確認する
• 組織内で承認された配布・更新基盤を利用する

HTTPSで公式サイトへ接続することは通信経路と接続先確認に重要ですが、公式サイト自体が侵害され、ファイルとハッシュ値を同時に置き換えられた場合まで、それだけで防げるわけではありません。

ファイル名・サイズ・更新日時では不十分

これらは補助情報にはなりますが、内容の完全性を確認する主要な根拠にはなりません。

5．ハッシュ値単独では送信元を認証しない

通常のハッシュ関数には鍵を使用しません。

そのため、同じデータを入手できる者であれば、誰でも同じハッシュ値を計算できます。

例えば、攻撃者がメッセージを書き換え、その書き換え後のメッセージから新しいハッシュ値を計算して、両方を置き換えれば、受信者がその値を信頼してしまう可能性があります。

したがって、鍵なしのハッシュ値だけでは、単独で次を確認できません。

• 特定の送信者が作成したこと
• 正規の送信者から届いたこと
• 送信者以外による偽造ではないこと
• 第三者に対する否認防止

ハッシュ値による完全性確認では、比較する基準値の真正性が別途確保されている必要があります。

6．SHA-256：256ビットのハッシュ値を生成する

SHA-256は、SHA-2ファミリに属する暗号学的ハッシュ関数です。

入力データの長さにかかわらず、256ビットのハッシュ値を生成します。

SGでは、次を押さえます。

• ハッシュ関数である
• 暗号化方式ではない
• 復号鍵を使用しない
• 出力長は256ビット
• ファイル・文書の完全性確認に利用できる
• HMACや、ハッシュ関数を利用するデジタル署名方式などで利用される
• 入力データの長さと出力長は同じではない

「SHA」という名称だけで永久に安全とは限らない

ハッシュ関数の安全性評価は、計算能力や暗号解析の進展によって変わります。

組織は、CRYPTREC暗号リストやNISTなどの公的な情報を確認し、目的に適したハッシュ関数を選択します。

暗号技術の危殆化と移行は、暗号方式の基本を扱う記事で整理します。

7．メッセージダイジェスト：ハッシュ関数の出力

メッセージダイジェストは、メッセージへハッシュ関数を適用して得られる値です。

一般に、次の語は近い意味で使用されます。

• ハッシュ値
• ハッシュ出力
• メッセージダイジェスト
• ダイジェスト

メッセージダイジェストは、デジタル署名だけに使う専用の値ではありません。

• ファイルの完全性確認
• HMACなど、ハッシュ関数を利用するメッセージ認証
• ハッシュ関数を利用するデジタル署名処理
• その他の暗号技術

で利用されます。

デジタル署名との関係

一般的なデジタル署名では、文書からメッセージダイジェストを生成し、その値を用いて署名を生成・検証します。

長い文書を固定長の値へまとめることで、効率的に署名処理を行えます。

ただし、本記事で扱うのは、メッセージダイジェストがハッシュ関数の出力であり、署名処理の入力として利用されるところまでです。

署名鍵・検証鍵、署名生成、署名検証、否認防止の詳細は「デジタル署名とタイムスタンプ」の記事で扱います。

8．MAC：共有秘密鍵を使って完全性と生成元を確認する

MACはMessage Authentication Codeの略で、日本語ではメッセージ認証符号と呼ばれます。

MACでは、送信者と受信者などが共有する秘密鍵を使用します。

基本的な流れ

1. 送信者と受信者が秘密鍵を共有する
2. 送信者がメッセージと共有秘密鍵からMACを生成する
3. 送信者がメッセージとMACを送信する
4. 受信者が同じ共有秘密鍵からMACを再計算する
5. 受信したMACと再計算したMACを比較する

値が一致すれば、次を確認できます。

• メッセージが途中で変更されていないこと
• 共有秘密鍵を持つ主体のいずれかによってMACが生成されたこと

攻撃者がメッセージを書き換えても、共有秘密鍵を持たなければ、書き換え後のメッセージに対応する正しいMACを生成することは困難です。

ハッシュ値との違い

9．HMAC：ハッシュ関数を利用するMAC

HMAC（Hash-based Message Authentication Code）は、暗号学的ハッシュ関数と共有秘密鍵を組み合わせてMACを構成する代表的な方式です。

名称にHashが含まれますが、通常の鍵なしハッシュとは異なります。

• 通常のハッシュ：鍵を使用しない
• HMAC：共有秘密鍵を使用する

例えば、HMAC-SHA-256は、SHA-256を構成要素として使用するHMACです。

単に「共有秘密鍵とメッセージを連結して一回ハッシュ化する」という自己流の方式ではなく、標準化されたHMACの構成を使用します。

MACはHMACだけではない

MACは、メッセージ認証符号という広い分類です。

HMACはその一方式であり、MACとHMACは完全な同義語ではありません。

MACには、ハッシュ関数を利用する方式のほかに、ブロック暗号を利用する方式などもあります。NISTもHMAC、CMAC、KMACを別方式として整理しています。

SGでは、次の関係を押さえれば十分です。

HMACは、ハッシュ関数と共有秘密鍵を利用するMAC方式である。

なお、HMAC・CMAC・KMACという用語自体はSGシラバスVer.4.1の用語例には明示されていません。本記事では、HMACをMACを理解するための代表的な具体例として扱い、CMAC・KMACは名称の紹介にとどめます。

10．MACの限界：機密性と否認防止は提供しない

MACで確認できる範囲と、確認できない範囲を分けます。

メッセージの内容を隠さない

MACを付けても、メッセージ本文は暗号化されません。

第三者へ内容を読ませたくない場合は、別途、適切な暗号化が必要です。

MACは「内容を隠す道具」ではなく、「改ざんと、共有秘密鍵を持たない第三者による偽造を検知する道具」です。

特定の一人が生成したことを第三者へ証明できない

送信者と受信者が同じ共有秘密鍵を持つ場合、双方が正しいMACを生成できます。

例えば、A社とB社が同じ共有秘密鍵を共有している場合、あるMACをA社が作ったのか、B社が作ったのかを、第三者はMACだけから区別できません。

そのため、MACは次の用途には適していません。

• 特定人物が生成したことを第三者へ証明する
• 契約後に生成者が否認できないようにする
• 公開の検証鍵で多数の第三者が検証する

これらにはデジタル署名が適しています。

「送信者の秘密鍵で生成し、公開鍵で検証」はMACではない

公開鍵と秘密鍵の組を使い、署名鍵で生成し検証鍵で検証する説明は、デジタル署名です。

MACは、送信者と受信者が共有する秘密鍵を使用します。

11．パスワード保存との関係

パスワード保存では、平文保存を避け、元のパスワードを直接保存しない方式を利用します。

ただし、パスワードを単純に一回だけSHA-256へ入力して保存する方法では、攻撃者が多数の候補を高速に試せるため、十分とはいえません。

一般に、次を組み合わせます。

• 利用者ごとに異なるソルト
• パスワード保存専用のハッシュ方式又は鍵導出方式
• 計算を意図的に重くするコスト設定
• システム性能の向上に応じたコストの見直し

なお、ソルト、鍵導出方式、コスト設定という用語名自体は、SGシラバスVer.4.1の用語例には明示されていません。本記事では、パスワード保存の考え方を理解するための関連知識として簡潔に扱います。

この論点の詳細は、パスワードへの攻撃を扱う記事と、利用者認証を扱う記事へ委ねます。

12．科目Bでの使われ方

科目Bでは、アルゴリズムの中身ではなく、その場面で使われている仕組みが目的に合っているかを判断する材料として使われます。

事例文に次の言葉が出てきたら、この記事の内容が判断材料になります。

担当者としては、まず何を確認したいのか（内容の変化か、生成元か、第三者への証明か）を整理し、現在の仕組みで足りるかを判断します。足りないと判断した場合は、上位者や関係部署へ報告して指示を仰ぎます。取引先や委託先との取決めに関わる場合は、契約担当者と協力して対応します。

13．仕組みを見分ける手順

1. 内容を隠したいのか、変化を確認したいのか

秘匿が目的なら暗号化、変化の確認ならハッシュ・MAC・署名を検討します。

1. 鍵を使用しているか

鍵を使わず基準値と比較するならハッシュ値です。

1. 共有秘密鍵を使用しているか

共有秘密鍵で生成・検証するならMACです。

1. ハッシュ関数と共有秘密鍵を組み合わせているか

その方式がHMACです。

1. 第三者も公開の鍵で検証する必要があるか

特定の署名者を第三者へ証明するならデジタル署名です。

1. 基準ハッシュ値の入手経路は信頼できるか

ファイルと基準値を同じ攻撃者が置き換えられる状態では不十分です。

1. MACへ機密性・否認防止を期待していないか

MACは内容を暗号化せず、共有者のうち誰が生成したかを第三者へ証明できません。

1. メッセージダイジェストを署名そのものと考えていないか

メッセージダイジェストはハッシュ関数の出力であり、署名処理に利用される値です。

よくある取り違え

まとめ

• ハッシュ関数は、任意長の入力から固定長のハッシュ値を生成する
• SHA-256は、入力の長さにかかわらず256ビットのハッシュ値を生成する
• ハッシュ関数は暗号化ではなく、復号鍵も存在しない
• 元データ候補を試して一致を探す攻撃は、復号ではなく推測攻撃
• 暗号学的ハッシュ関数には、原像計算困難性、第二原像計算困難性、衝突耐性などが求められる
• 衝突が絶対に存在しないのではなく、現実的に見つけにくいことが重要
• ファイルの完全性確認では、計算値を信頼できる基準ハッシュ値と比較する
• ハッシュ値が一致しても、作成者、送信者、ファイルの安全性まで自動的に証明されない
• 鍵なしハッシュは誰でも計算できるため、単独では生成元を認証しない
• メッセージダイジェストは、ハッシュ関数を適用して得られるハッシュ値
• MACは共有秘密鍵を使用し、完全性と、鍵を持つ主体のいずれかによる生成を確認する
• HMACは、暗号学的ハッシュ関数と共有秘密鍵を利用するMAC方式
• MACはメッセージを暗号化せず、機密性を提供しない
• 共有者双方が同じMACを生成できるため、特定人物による生成を第三者へ証明する否認防止には向かない
• デジタル署名は署名鍵と検証鍵を用い、詳細は「デジタル署名とタイムスタンプ」の記事で扱う
• パスワード保存では、単純な一回のSHA-256だけにせず、ソルトとコストを伴う適切な方式を利用する
• 科目Bでは、鍵の有無、鍵の種類、基準値の信頼性、誰が検証するかを確認する

関連記事

• C1-T08：パスワードへの攻撃
• C2-T01：暗号方式の基本（鍵管理・危殆化を含む）
• C2-T04：デジタル署名とタイムスタンプ
• C2-T05：PKIとデジタル証明書
• C2-T06：利用者認証の3要素と生体認証
• C5-T11：セキュアプロトコルと実装技術

本記事は、2026年8月3日時点のSGシラバスVer.4.1を基準に作成しています。

参考資料

• IPA「情報セキュリティマネジメント試験（レベル2）シラバス Ver.4.1」
• NIST FIPS 180-4「Secure Hash Standard」
• NIST「Hash Functions」
• NIST FIPS 198-1「The Keyed-Hash Message Authentication Code (HMAC)」
• NIST「Message Authentication Codes」
• NIST FIPS 186-5「Digital Signature Standard」
• NIST SP 800-63B-4「Digital Identity Guidelines: Authentication and Authenticator Management」

関連する問題

• 情報セキュリティマネジメント 暗号・認証・PKI 択一式（応用） 第1問〜第5問
• 情報セキュリティマネジメント 暗号・認証・PKI 一問一答 第6問〜第10問
• 情報セキュリティマネジメント 暗号・認証・PKI 一問一答 第11問〜第15問

---