ハッシュコードとチェックサム-違いは何ですか？

私の理解では、ハッシュコードとチェックサムは似ています。データブロックに対して計算された、比較的一意の数値です。

つまり、同じ数値のハッシュ/チェックサム値を生成する2つのデータブロックの確率は、アプリケーションの目的で無視できるほど十分に低いです。

それで、同じことを表す2つの単語があるのでしょうか、それともハッシュコードとチェックサムの間に重要な違いがあるのでしょうか。

私はと言うでしょうチェックサムが 必然であるハッシュコード。ただし、すべてのハッシュコードが適切なチェックサムを作成するわけではありません。

チェックサムには特別な目的があります--- データの整合性を検証またはチェックします（エラー訂正を許可することで、それを超えるものもあります）。「適切な」チェックサムは簡単に計算でき、多くのタイプのデータ破損（たとえば、1、2、3の誤ったビット）を検出できます。

ハッシュコードは、データをある値にマッピングする数学関数を単に記述したものです。データ構造（ハッシュテーブルなど）でインデックスを作成する手段として使用する場合は、低い衝突確率が望ましいです。

それぞれの背後には異なる目的があります。

• ハッシュコード-ドメイン全体でランダムになるように設計されています（ハッシュテーブルなどでの衝突を最小限に抑えるため）。暗号化ハッシュコードは、逆に計算上実行できないように設計されています。
• チェックサム-データの最も一般的なエラーを検出し、多くの場合、計算が高速になるように設計されています（データの高速ストリームを効率的にチェックサムするため）。

実際には、同じ機能が両方の目的に適していることがよくあります。特に、計算コストが余裕がある場合は、暗号学的に強力なハッシュコードが優れたチェックサムです（ランダムエラーが強力なハッシュ関数を壊すことはほとんど不可能です）。

確かにいくつかの違いがあります：

• チェックサムは、入力が異なる場合（できるだけ頻繁に）に異なる必要があるだけですが、計算が高速であることがほぼ同じくらい重要です。
• ハッシュコード（ハッシュテーブルで使用するため）には同じ要件があり、さらに、特に類似する入力の場合、コードスペース全体に均等に分散する必要があります。
• 暗号化ハッシュには、ハッシュを指定するというより厳しい要件があるため、このハッシュを生成する入力を作成することはできません。計算時間は2番目に来ます。アプリケーションによっては、ハッシュが非常に遅いことが（ブルートフォース攻撃に対抗するために）遅いことが望ましい場合さえあります。

ハッシュコードとチェックサムの両方を使用して、データ項目から短い数値を作成します。違いは、データ項目に小さな変更が加えられた場合でも、チェックサム値が変更されることです。ハッシュ値の場合、要件は、実際のデータアイテムが異なるハッシュ値を持つ必要があることだけです。

明確な例は文字列です。文字列のチェックサムには、すべてのビットが含まれている必要があり、順序が重要です。一方、ハッシュコードは、多くの場合、長さが制限されたプレフィックスのチェックサムとして実装できます。これは、「aaaaaaaaaaba」は「aaaaaaaaaaab」と同じハッシュになることを意味しますが、ハッシュアルゴリズムはこのような衝突に対処できます。

ウィキペディアはそれをうまく置きます：

チェックサム関数は、ハッシュ関数、フィンガープリント、ランダム化関数、および暗号化ハッシュ関数に関連しています。ただし、これらの概念はそれぞれ異なるアプリケーションを持っているため、異なる設計目標があります。チェックディジットとパリティビットはチェックサムの特殊なケースであり、データの小さなブロック（社会保障番号、銀行口座番号、コンピューターワード、シングルバイトなど）に適しています。一部のエラー修正コードは、一般的なエラーを検出するだけでなく、特定の場合に元のデータを復元できる特別なチェックサムに基づいています。

チェックサムは、偶発的な変更から保護します。

暗号化ハッシュは、非常にやる気のある攻撃者から保護します。

ワイヤ上でビットを送信すると、一部のビットが反転、削除、または挿入される場合があります。このような事故を受信者が検出できるように（場合によっては修正できるようにするため）、送信者はチェックサムを使用します。

しかし、誰かがネットワーク上で積極的かつインテリジェントにメッセージを変更していると想定し、この種の攻撃者から保護したい場合は、暗号化ハッシュを使用します（ハッシュに暗号で署名することや、セカンダリチャネルなどを使用することは無視します。質問はこれに逃げていないようです）。

ハッシュとチェックサムはどちらもファイルの内容に基づいて値を作成するという点で似ていますが、ハッシュはチェックサムを作成することと同じではありません。チェックサムはデータの整合性を検証（チェック）し、データ送信エラーを識別することを目的としていますが、ハッシュはデータの一意のデジタルフィンガープリントを作成するように設計されています。

出典：CompTIA®Security +ネットワークセキュリティ基礎ガイド-第5版-Mark Ciampa-191ページ

最近は交換可能ですが、昔はチェックサムはすべてのデータを（通常はバイト単位で）追加し、最後に1バイトをその値に追加するという非常に単純な手法でした。元のデータが破損していないかどうかを確認します。チェックビットに似ていますが、バイトが含まれています。

ハッシュコードとチェックサム関数の違いは、それらは異なる目的のために設計されていることです。

• チェックサムは、入力の何かが変更されたかどうかを確認するために使用されます。

• ハッシュコードは、入力の何かが変更されたかどうかを確認するために使用され、、可能な限り、個々のハッシュコード値の間ずっと「距離」として持っています。

  また、早期にハッシュコード値のツリー/クラスター/バケットを形成する機能のように、このルールに反して、ハッシュ関数にさらに要件があるかもしれません。

  そして、いくつかの共有初期ランダム化を追加すると、最新の暗号化/鍵交換の概念に到達します。

確率について：

たとえば、入力データが実際には常に変化していると仮定します（100％の時間）。そして、1ビットのハッシュ/チェックサム値を生成する「完全な」ハッシュ/チェックサム関数があるとしましょう。したがって、ランダムな入力データに対して、50％の確率で異なるハッシュ/チェックサム値を取得します。

• ランダム入力データの正確に1ビットが変更された場合、入力データの大きさに関係なく、その時間を100％検出できます。

• ランダム入力データの2ビットが変更された場合、「変更」を検出する確率は2で除算されます。これは、両方の変更が互いに無効になる可能性があり、ハッシュ/チェックサム関数が入力データの2ビットが実際に異なることを検出しないためです。 。

  ...

つまり、入力データのビット数がハッシュ/チェックサム値のビット数よりも数倍大きい場合、実際には、異なる入力値に対して異なるハッシュ/チェックサム値を取得する確率が低くなり、一定。

ファイルまたはデータが破損していないことを確認するために使用できるファイルまたはデータの一部に対して作成されたコード（数値またはその他）を参照するときは、チェックサムという言葉を使用する傾向があります。私が遭遇する最も一般的な使用法は、ネットワークを介して送信されたファイルが（意図的にまたはその他の方法で）変更されていないことを確認することです。

Redisクラスターデータシャーディングでは、hash slotを使用して、どのノードに移動するかを決定します。以下のモジュロ演算を例にとります。

123 % 9 = 6
122 % 9 = 5
141 % 9 = 6

の 6異なる入力間に二回アップします。ハッシュの目的は、単に入力値を出力値にマップすることであり、一意性は取引の一部ではありません。したがって、同じ出力を生成する2つの異なる入力は、ハッシュの世界では問題ありません。

一方、チェックサムは、その目的がマッピングではなくデータの破損を検出するためであるため、入力の1ビットが変化しても、出力を異なるものにする必要があります。したがって、同じ出力を生成する2つの異なる入力は、チェックサムでは受け入れられません。

チェックサムは、oring（論理和、つまり合計）によってデータフィールドから生成された数値です。チェックサムは、それが生成されたデータフィールド内の任意のビットまたはビット数の破損を検出する機能を備えています。つまり、すべてのエラーをチェックし、エラーを修正できません。チェックサムのサイズは元のデータよりも小さいため、チェックサムはハッシュです。はい、チェックサムはデータフィールドのビット位置にまったく影響されないため、衝突が発生します。

巡回冗長検査（CRC）はまったく異なる、より複雑なものであり、チェックサムとは呼ばれません。それは、それが生成されたデータフィールド内の任意の選択された数の個々の破損ビットを訂正する能力を有する多項式シリーズのアプリケーションです。CRCを作成すると、元のデータフィールドよりもサイズが大きくなります（チェックサムとは異なります）。したがって、「冗長性」という単語を含む名前と、エラー修正機能に対して支払う価格です。したがって、CRCはハッシュではなく、混乱が生じたり、チェックサムとして名前を付けたりしてはなりません。冗長性により、元のデータのサイズが必ず増えるためです。