CRCアルゴリズムは通常、ハミング距離の条件下でのエラー検出の保証を備えています。 ビットフリップの数が限られている場合、CRCは_必然的に_異なる結果を生成します。

これは、エラーが数ビットしか反転しないと推定される状況で便利です。
ほんの数十年前、これは比較的一般的でした。特に送信シナリオでは、基になる信号がまだ非常に「生」であったため、物理層での検出されないビットフリップが問題でした。

ただし、この物件には流通費がかかります。 「安全な」ハミング距離を超えると、衝突の可能性が低くなります。 これは鳩の巣原理の論理的帰結です。 どれだけ悪いですか？ まあ、それは正確なCRCに依存しますが、私は良いCRCが3倍から7倍悪い範囲にあると予想しています。 それはかなり聞こえるかもしれませんが、それは2〜3ビットの分散削減であるため、それほどひどいことではありません。 それでも。

「理想的な」分配プロパティを特徴とするハッシュとは対照的です。単一ビットであろうと完全に異なる出力であろうと、変更は衝突を生成する確率が正確に1/2 ^ nです。 把握するのは簡単です。衝突のリスクは常に同じです。 CRCと直接比較すると、ハミング距離が小さい場合は衝突率が悪くなりますが（> 0であるため）、ハミング距離が大きい場合は良好です。

最近は早送りし、状況は根本的に変わりました。 物理メディアの上に、エラー検出および訂正ロジックのレイヤーがあります。 フラッシュブロックからビットを抽出することも、Bluetoothチャネルからビットを読み取ることもできません。 もう意味がありません。 これらのプロトコルには、ステートフルブロックロジックが組み込まれています。これは、より複雑で復元力があり、物理層の永続的なノイズを常に補正します。 それらが失敗した場合、それは単一のフリップを生成することはありません。むしろ、完全なデータ領域が完全にシャンブルされ、すべてゼロ、またはランダムノイズにさえなります。

この新しい環境では、エラーが発生した場合、エラーは「ビットフリップ」カテゴリに含まれなくなります。 その場合、CRCの配布特性が責任になります。 純粋なハッシュは、実際には衝突を引き起こす可能性が低くなります。

これは、チェックサムのみを検討する場合です。
「理想的な」ハッシュの追加のプロパティは、ハッシュからビットのセグメントを抽出するときに、この1 / 2^n衝突確率を特徴とすることです。これは、次のような他の構造のビットのソースとして非常に重要です。ハッシュテーブルまたはブルームフィルター。 対照的に、CRCはそのような保証を提供しません。 一部のビットは最終的に非常に予測可能または高度に相関し、ハッシュ目的でそれらを抽出すると、分散がはるかに悪化します。

チェックサムとハッシュは単に2つの異なるドメインであり、混同しないでください。 確かに、それは理論です。 問題は、これは利便性と現場での実践を無視しているということです。 複数の目的のために1つの「ミキサー」を持つことは便利であり、プログラマーは1つに落ち着き、それを忘れてしまいます。 crc32が「十分にランダム」であると感じたという理由だけで、ハッシュに使用されたcrc32を見た回数を数えることはできません。 それは起こるべきではないと言うのは簡単ですが、常に起こります。
この環境では、ユーザーの期待に一致するため、両方のユースケースで適切に機能するように設計されたソリューションを提案することは理にかなっています。

PIC / Arduinoの群集の中で、人々は今でも古い単純な8ビットチェックサム、16ビットフレッチャーサム、または16ビットCRCを使用しています。
（...）
8ビットまたは16ビットに減らすと、ハッシュ関数に本質的に悪いものがありますか？

優れたハッシュの特性により、ハッシュから8ビットまたは16ビットを抽出することは確かに可能であり、1/256または1/65535の衝突確率が発生します。 これについては何の懸念もありません。

ただ、_history_のレイテンシーを受け入れる必要があります。 人々は、チェックサムに特定のチェックサム関数を使用するなど、特定の方法に慣れています。 より最近の、そして潜在的により良い解決策がそこにあるとしても、習慣は速く変化しません。

CRCアルゴリズムは通常、ハミング距離の条件下でのエラー検出の保証を備えています。 ビットフリップの数が限られている場合、CRCは_必然的に_異なる結果を生成します。

これは、エラーが数ビットしか反転しないと推定される状況で便利です。
ほんの数十年前、これは比較的一般的でした。特に送信シナリオでは、基になる信号がまだ非常に「生」であったため、物理層での検出されないビットフリップが問題でした。

ただし、この物件には流通費がかかります。 「安全な」ハミング距離を超えると、衝突の可能性が低くなります。 これは鳩の巣原理の論理的帰結です。 どれだけ悪いですか？ まあ、それは正確なCRCに依存しますが、私は良いCRCが3倍から7倍悪い範囲にあると予想しています。 それはかなり聞こえるかもしれませんが、それは2〜3ビットの分散削減であるため、それほどひどいことではありません。 それでも。

「理想的な」分配プロパティを特徴とするハッシュとは対照的です。単一ビットであろうと完全に異なる出力であろうと、変更は衝突を生成する確率が正確に1/2 ^ nです。 把握するのは簡単です。衝突のリスクは常に同じです。 CRCと直接比較すると、ハミング距離が小さい場合は衝突率が低くなりますが（> 0であるため）、ハミング距離が大きい場合は衝突率が高くなります。

最近は早送りし、状況は根本的に変わりました。 物理メディアの上に、エラー検出および訂正ロジックのレイヤーがあります。 フラッシュブロックからビットを抽出することも、Bluetoothチャネルからビットを読み取ることもできません。 もう意味がありません。 これらのプロトコルには、ステートフルブロックロジックが組み込まれています。これは、より複雑で復元力があり、物理層の永続的なノイズを常に補正します。 それらが失敗した場合、それは単一のフリップを生成することはありません。むしろ、完全なデータ領域が完全にシャンブルされ、すべてゼロ、またはランダムノイズにさえなります。

この新しい環境では、エラーが発生した場合、エラーは「ビットフリップ」カテゴリに含まれなくなります。 その場合、CRCの配布特性が責任になります。 純粋なハッシュは、実際には衝突を引き起こす可能性が低くなります。

これは、チェックサムのみを検討する場合です。
「理想的な」ハッシュの追加のプロパティは、ハッシュからビットのセグメントを抽出するときに、この1 / 2^n衝突確率を特徴とすることです。これは、次のような他の構造のビットのソースとして非常に重要です。ハッシュテーブルまたはブルームフィルター。 対照的に、CRCはそのような保証を提供しません。 一部のビットは最終的に非常に予測可能または高度に相関し、ハッシュ目的でそれらを抽出すると、分散がはるかに悪化します。

チェックサムとハッシュは単に2つの異なるドメインであり、混同しないでください。 確かに、それは理論です。 問題は、これは利便性と現場での実践を無視しているということです。 複数の目的のために1つの「ミキサー」を持つことは便利であり、プログラマーは1つに落ち着き、それを忘れてしまいます。 crc32が「十分にランダム」であると感じたという理由だけで、ハッシュに使用されたcrc32を見た回数を数えることはできません。 それは起こるべきではないと言うのは簡単ですが、常に起こります。
この環境では、ユーザーの期待に一致するため、両方のユースケースで適切に機能するように設計されたソリューションを提案することは理にかなっています。

PIC / Arduinoの群集の中で、人々は今でも古い単純な8ビットチェックサム、16ビットフレッチャーサム、または16ビットCRCを使用しています。
（...）
8ビットまたは16ビットに減らすと、ハッシュ関数に本質的に悪いものがありますか？

優れたハッシュの特性により、ハッシュから8ビットまたは16ビットを抽出することは確かに可能であり、1/256または1/65535の衝突確率が発生します。 これについては何の懸念もありません。

ただ、_history_のレイテンシーを受け入れる必要があります。 人々は、チェックサムに特定のチェックサム関数を使用するなど、特定の方法に慣れています。 より最近の、そして潜在的により良い解決策がそこにあるとしても、習慣は速く変化しません。

CRC32とHD = 6を使用すると、5ビットエラーを検出でき、最大2 ^ 31 =約204MBのバーストを検出できることがわかっています。
すべてのシングルビットエラーを検出します
xxHashでは、エラーを検出できないように、何ビットを変更する必要がありますか？
ハッシュでは、1ビットの変更でもまったく異なるダイジェストが作成されることは知っていますが、衝突を作成するために必要なビット数をどのように計算できますか？
別の質問はあなたが言ったようにです：

対照的に、CRCはそのような保証を提供しません。 一部のビットは最終的に非常に予測可能または高度に相関し、ハッシュ目的でそれらを抽出すると、分散がはるかに悪化します。

なぜそれが悪いのですか？ ビットが何らかの形で相関している場合、この相関関係を使用して破損したファイルを修復できますか？

xxHashでは、エラー（または衝突）を検出できないように変更する必要のあるビット数

1ビット。

xxHashは非暗号化ハッシュ関数であり、チェックサムではありません。 ハミング距離や衝突耐性の保証はありません。

それはそれでまともな仕事をすることができますが、それは最良の選択ではありません。 ペンチをレンチとして使うようなものです。 確かに、それは仕事を成し遂げますが、それは実際のレンチよりも効果が低く、損傷を引き起こす可能性があります。

xxHashでは、エラー（または衝突）を検出できないように変更する必要のあるビット数

1ビット。

xxHashは非暗号化ハッシュ関数であり、チェックサムではありません。 ハミング距離や衝突耐性の保証はありません。

それはそれでまともな仕事をすることができますが、それは最良の選択ではありません。 ペンチをレンチとして使うようなものです。 確かに、それは仕事を成し遂げますが、それは実際のレンチよりも効果が低く、損傷を引き起こす可能性があります。

1ビットのデータを変更するだけでデコーダーをだますことができるということですか？
衝突を引き起こす可能性がありますか？ （それは怖いです）そしてそのような衝突の確率はダイジェストサイズに依存します

1ビットのデータを変更するだけでデコーダーをだますことができるということですか？

2つの異なるコンテンツから生成されたハッシュ値を考慮すると、衝突の確率は常に1 / 2^64 （ xxh64やxxh3などの高品質の64ビットハッシュアルゴリズムの場合）。これら2つのコンテンツ間の変更の量。

実際、少なくとも理論的には、1ビットの変更で衝突が発生する可能性があることを意味します。

ここで、この確率は1 / 2^64であることに注意してください。これは、ほとんど微小です。
人々はこのトピックを理解するのが比較的苦手です。 彼らは時々それを「小さい」と混同します。それはほとんどの人の心の中で〜10％のような具体的な量として認識される傾向があります。

より正確なアイデアを得るために、私はこの表を参照するのが好きです：

つまり、 1 / 2 ^ 64は、彗星を直接頭に乗せる可能性よりもはるかに低く、国営宝くじに_3回連続で当選するよりも低くなります_（かなり疑わしいです）。 これは実際には「null」にはるかに近いです。 どのシステムのほとんどのコンポーネントも、他のソフトウェアバグの原因から始めて、それよりもはるかに高い確率で破損する可能性があります。

このような理論的な1ビットの衝突を見つけたい場合は、この問題の解決策を総当たり攻撃するために、かなり巨大な入力とかなり信じられないほどの量の電力が必要になります。 それでも、解決策は存在しない可能性があります。採用されている算術演算の性質を考慮すると、1ビットの変更で衝突を生成することが不可能であっても驚かないでしょう。 私自身の賭けは、少なくとも2ビットが必要であり、それでも、目的を達成する機会を得るには、特定の入力の位置にそれらを配置する必要があり、そのような変更はもはや「ランダム」ではないため、非暗号化ハッシュ。

しかし、引用されたテキストはすでにこれをすべて説明していると思います：実際のcrcはハミング距離を保証しています。 これは便利な場合があり、信号がビットレベルで変更されやすい場合や、チェックサム自体がかなり小さい場合（16ビットまたは32ビット）、以前ははるかに理にかなっています。 16ビットハッシュアルゴリズムでは、ビットフリップが非常に少ない衝突を見逃す可能性が無視できないため、タスクへの適合性が低くなります。 しかし、64ビットまたは128ビットのハッシュがテーブルにあるので、衝突の可能性、つまり検出されない破損の可能性が計り知れないほど小さいという理由だけで、これはもはや危険なオプションではないと思います。

一部のビットは最終的に非常に予測可能または高度に相関し、ハッシュ目的でそれらを抽出すると、分散がはるかに悪化します。

なぜそれが悪いのですか？

ハッシュは一般に、チェックサムの置き換えよりも多くの用途があります。
実際、ほとんどの場合、ハッシュアルゴリズムの目的は、ハッシュテーブル内の位置を指定するためにいくつかのランダムビットを提供することです。 これらのビットの一部がコンテンツに応じて予測可能になると、ハッシュテーブル内の位置の分布が「ランダム」でなくなり、その結果、一部のセルが他のセルよりも速くオーバーフローし、ハッシュテーブルのパフォーマンスに悪影響を及ぼします。 。

ビットが何らかの形で相関している場合、この相関関係を使用して破損したファイルを修復できますか？

これはまったく別のトピックです。
損傷した入力をCRCで修復することはありません。 CRCはエラーを検出することしかできず、修復することはできません。

自己修復データはトピックであり、畳み込み符号などのさまざまな（そしてはるかに計算に関係する）手法を使用します。 これははるかに複雑です。

このような理論的な1ビットの衝突を見つけたい場合は、この問題の解決策を総当たり攻撃するために、かなり巨大な入力とかなり信じられないほどの量の電力が必要になります。 それでも、解決策は存在しない可能性があります。採用されている算術演算の性質を考慮すると、1ビットの変更で衝突を生成することが不可能であっても驚かないでしょう。 私自身の賭けは、少なくとも2ビットが必要であり、それでも、目的を達成する機会を得るには、特定の入力の位置にそれらを配置する必要があり、そのような変更はもはや「ランダム」ではないため、非暗号化ハッシュ。

261は、XXH3の64ビットバリアントでのシングルビット衝突を示していますが、シードに依存しており、ランダム入力で発生する可能性はほとんどありません。

確かに; より完全にするために、私の前のステートメントは、240バイトを超える入力の大きなサイズのセクションに向けられていました。

ただし、入力が64ビットのsecretいずれかと正確に一致する必要がある限られたサイズの範囲では、シングルビットの衝突が発生する可能性があります。 入力がランダムである（つまり、衝突を生成するように設計されていない）と仮定すると、正確な場所での正確な64ビット入力に基づく衝突はまだこの1 / 2^64領域内にあるため、許容できると感じました。 さらに、一致するsecretを効果的に_秘密_にすることができるため、外部の攻撃者はそれを見つけるためにブルートフォース攻撃を行う必要があります。

1ビットのデータを変更するだけでデコーダーをだますことができるということですか？

2つの異なるコンテンツから生成されたハッシュ値を考慮すると、衝突の確率は常に1 / 2^64 （ xxh64やxxh3などの高品質の64ビットハッシュアルゴリズムの場合）。これら2つのコンテンツ間の変更の量。

実際、少なくとも理論的には、1ビットの変更で衝突が発生する可能性があることを意味します。

ここで、この確率は1 / 2^64であることに注意してください。これは、ほとんど微小です。
人々はこのトピックを理解するのが比較的苦手です。 彼らは時々それを「小さい」と混同します。それはほとんどの人の心の中で〜10％のような具体的な量として認識される傾向があります。

より正確なアイデアを得るために、私はこの表を参照するのが好きです：

つまり、 1 / 2 ^ 64は、彗星を直接頭に乗せる可能性よりもはるかに低く、国営宝くじに_3回連続で当選するよりも低くなります_（かなり疑わしいです）。 これは実際には「null」にはるかに近いです。 どのシステムのほとんどのコンポーネントも、他のソフトウェアバグの原因から始めて、それよりもはるかに高い確率で破損する可能性があります。

このような理論的な1ビットの衝突を見つけたい場合は、この問題の解決策を総当たり攻撃するために、かなり巨大な入力とかなり信じられないほどの量の電力が必要になります。 それでも、解決策は存在しない可能性があります。採用されている算術演算の性質を考慮すると、1ビットの変更で衝突を生成することが不可能であっても驚かないでしょう。 私自身の賭けは、少なくとも2ビットが必要であり、それでも、目的を達成する機会を得るには、特定の入力の位置にそれらを配置する必要があり、そのような変更はもはや「ランダム」ではないため、非暗号化ハッシュ。

しかし、引用されたテキストはすでにこれをすべて説明していると思います：実際のcrcはハミング距離を保証しています。 これは便利な場合があり、信号がビットレベルで変更されやすい場合や、チェックサム自体がかなり小さい場合（16ビットまたは32ビット）、以前ははるかに理にかなっています。 16ビットハッシュアルゴリズムでは、ビットフリップが非常に少ない衝突を見逃す可能性が無視できないため、タスクへの適合性が低くなります。 しかし、64ビットまたは128ビットのハッシュがテーブルにあるので、衝突の可能性、つまり検出されない破損の可能性が計り知れないほど小さいという理由だけで、これはもはや危険なオプションではないと思います。

一部のビットは最終的に非常に予測可能または高度に相関し、ハッシュ目的でそれらを抽出すると、分散がはるかに悪化します。

なぜそれが悪いのですか？

ハッシュは一般に、チェックサムの置き換えよりも多くの用途があります。
実際、ほとんどの場合、ハッシュアルゴリズムの目的は、ハッシュテーブル内の位置を指定するためにいくつかのランダムビットを提供することです。 これらのビットの一部がコンテンツに応じて予測可能になると、ハッシュテーブル内の位置の分布が「ランダム」でなくなり、その結果、一部のセルが他のセルよりも速くオーバーフローし、ハッシュテーブルのパフォーマンスに悪影響を及ぼします。 。

ビットが何らかの形で相関している場合、この相関関係を使用して破損したファイルを修復できますか？

これはまったく別のトピックです。
損傷した入力をCRCで修復することはありません。 CRCはエラーを検出することしかできず、修復することはできません。

自己修復データはトピックであり、畳み込み符号などのさまざまな（そしてはるかに計算に関係する）手法を使用します。 これははるかに複雑です。

これらのシナリオを確認できますか？

1. LZ4には、データブロックごとにコンテンツチェックサムがあります。1GBファイルの10 ^ 6パケットがあると考えてください。
   衝突の確率は1/2 ^ 32 = 0.0000000002です。つまり、10 ^ 10（この巨大なサイズ）のパケットを送信すると、（鳩の巣原理に基づいて）2回の衝突が発生する可能性がありますが、この量より少ない場合、確率は衝突が発生すると、すべてのエラーを検出できるように大幅に低下し、デコーダーがチェックサムを計算してパケットチェックサムと比較します。これは正しいですか？
2. コンテンツチェックサムは、圧縮ファイルのチェックサムを計算します（これはオプションであり、順序が狂っていることを検出したり、衝突の可能性を減らしたりするために使用できます（CCを使用する前は、衝突の確率は1/2 ^ 32であり、その後、 1/2 ^ 64になります。）

説明されているシナリオは次のとおりです。

• LZ4で圧縮されたデータが破損しています（これは、それ自体ではすでにかなりまれなイベントです）
• ハッシュの衝突により、破損が検出されないままになっています。

LZ4フレーム形式は、コンパニオンチェックサムとして32ビットハッシュであるXXH32使用します。
デフォルトでは、フレーム全体のコンテンツ、より正確にはフレームの_uncompressed_コンテンツ（解凍後）に適用されるため、送信プロセスとデコードプロセスの両方が検証されます。
オプションで各ブロックに適用することもできます。その場合、各ブロックの_compressed_コンテンツをチェックサムします。
両方とも累積できます。

検出されないままにするには、破損が___all___の該当するチェックサムに正常に合格する必要があります。
ブロックチェックサムが有効になっていると仮定し、破損が完全に1つのブロック内にあると仮定すると、ブロックとフレームチェックサムの両方を通過する可能性は確かに1 / 2^32 x 1 / 2^32 = 1 / 2^64です。

現在、複数の破損イベントがあるため、または単一の大きな破損セクションが連続するブロックをカバーしているために、破損したデータが複数のブロックに存在する場合、破損が検出されないままになるのはさらに困難です。 関連するブロックチェックサムのそれぞれとの衝突を生成する必要があります。
たとえば、破損が2つのブロックに広がっていると仮定すると、この破損が検出されないままになる可能性は1 / 2^32 x 1 / 2^32 x 1 / 2^32 = 1 / 2^96です。 天文学的に小さい。

破損した各ブロックが、その上にある解凍プロセスによってデコード不能として検出される可能性があるという事実をカウントしていません。

そうです、ブロックチェックサムとフレームチェックサムを組み合わせると、破損イベントを検出する可能性が劇的に高まります。

説明されているシナリオは次のとおりです。

* LZ4-compressed data being corrupted (which is already a pretty rare event by itself)

* Corruption remaining undetected due to hash collision.

LZ4フレーム形式は、コンパニオンチェックサムとして32ビットハッシュであるXXH32使用します。
デフォルトでは、フレーム全体のコンテンツ、より正確にはフレームの_uncompressed_コンテンツ（解凍後）に適用されるため、送信プロセスとデコードプロセスの両方が検証されます。
オプションで各ブロックに適用することもできます。その場合、各ブロックの_compressed_コンテンツをチェックサムします。
両方とも累積できます。

検出されないままにするには、破損が_すべての_該当するチェックサムに正常に合格する必要があります。
ブロックチェックサムが有効になっていると仮定し、破損が完全に1つのブロック内にあると仮定すると、ブロックとフレームチェックサムの両方を通過する可能性は確かに1 / 2^32 x 1 / 2^32 = 1 / 2^64です。

現在、複数の破損イベントがあるため、または単一の大きな破損セクションが連続するブロックをカバーしているために、破損したデータが複数のブロックに存在する場合、破損が検出されないままになるのはさらに困難です。 関連するブロックチェックサムのそれぞれとの衝突を生成する必要があります。
たとえば、破損が2つのブロックに広がっていると仮定すると、この破損が検出されないままになる可能性は1 / 2^32 x 1 / 2^32 x 1 / 2^32 = 1 / 2^96です。 天文学的に小さい。

破損した各ブロックが、その上にある解凍プロセスによってデコード不能として検出される可能性があるという事実をカウントしていません。

そうです、ブロックチェックサムとフレームチェックサムを組み合わせると、破損イベントを検出する可能性が劇的に高まります。

LZ4をその場で使用することは可能ですか？ つまり、データを取得したらすぐにデータを圧縮/解凍します。 どういうわけかパイプラインです。
xxHashはどうですか？

LZ4をその場で使用することは可能ですか？ つまり、データを取得したらすぐにデータを圧縮/解凍します。

これがストリーミングモードです。 はい、可能です。

xxHashはどうですか？

フレームチェックサムは継続的に更新されますが、結果はフレームの最後でのみ生成されます。 したがって、フレーム終了イベントまで比較するチェックサム結果はありません（ストリームは複数の追加フレームで構成されている場合がありますが、通常はそうではありません）。

対照的に、ブロックチェックサムは各ブロックで作成されるため、ストリーミング中に定期的に作成およびチェックされます。

両方のチェックサムはXXH32ます。