web-dev-qa-db-ja.com

データ長とCRC長

8ビット、16ビット、および32ビットのCRCを見てきました。

どの時点でより広いCRCにジャンプする必要がありますか？

私の腸の反応は、データ長に基づいているということです：

  1. 1-100バイト：8ビットCRC
  2. 101-1000バイト：16ビットCRC
  3. 1001-???バイト：32ビットCRC

編集：CRCとロットの答えについてのウィキペディアのページを見て、ここに私たちが持っているものがあります：

<64バイト：8ビットCRC

<16Kバイト：16ビットCRC

<512Mバイト：32ビットCRC

crccrc32
33
Robert

これは研究トピックではありません。それは本当によく理解されています： http://en.wikipedia.org/wiki/Cyclic_redundancy_check

計算は非常に簡単です。 8ビットCRCは、すべてのメッセージを256個の値のいずれかにまとめます。メッセージの長さが数バイトを超える場合、同じハッシュ値を持つ複数のメッセージの可能性がますます高くなります。

同様に、16ビットCRCは、65,536個の利用可能なハッシュ値のいずれかを提供します。これらの値のいずれかを持つ2つのメッセージの確率はどのくらいですか？

32ビットCRCは、約40億の利用可能なハッシュ値を提供します。

ウィキペディアの記事から：「最大合計ブロック長は2**r − 1と等しい」。それは少しです。 2**9 - 1が511ビットであることを確認するために多くの調査を行う必要はありません。 CRC-8を使用すると、64バイトより長い複数のメッセージのCRCチェックサム値が同じになります。

31
S.Lott

CRCの有効性は、複数の要因に依存しています。 CRCのサイズを選択するだけでなく、使用する生成多項式も選択する必要があります。以下に応じて、複雑で非直感的なトレードオフがあります。

  • チャネルの予想ビットエラーレート。
  • エラーがバーストで発生する傾向があるか、または分散する傾向があるか（バーストが一般的です）
  • 保護されるデータの長さ-最大長、最小長、および分布。

2004年のディペンダブルシステムとネットワークに関する国際会議の議事録に掲載された、Philip KoopmanとTridib Chakravartyによる組み込みネットワークの巡回冗長コード多項式選択は非常に優れた概要を提供し、いくつかの推奨事項を示しています。さらに理解を深めるための参考文献も提供します。

http://www.ece.cmu.edu/~koopman/roses/dsn04/koopman04_crc_poly_embedded.pdf

6
Mary Ann Mojica

CRCの長さとファイルサイズの選択は、主に、「正しい」入力と3ビットまたはそれ以下の差がある入力の方が、大きく異なる場合よりも重要です。 2つの入力が大きく異なる場合、誤った一致の可能性は、ほとんどの形式の8ビットチェック値（CRCを含む）で約1/256、ほとんどの形式の16ビットチェック値（CRCを含む）で1/65536になります。など。CRCの利点は、非常に類似した入力の処理にあります。

多項式が長さ128の2つの周期を生成する8ビットCRCの場合、検出されないパケットよりも短いパケットのシングル、ダブル、またはトリプルビットエラーの割合は1/256にならず、ゼロになります。同様に、32768ビット以下のパケットを使用して、期間32768の16ビットCRCを使用します。

ただし、パケットがCRC期間より長い場合、エラーのあるビット間の距離がCRC期間の倍数であれば、ダブルビットエラーは検出されません。それは恐らくありそうなシナリオとは思えないかもしれませんが、CRC8は「パケットが完全にスクランブルされている」エラーをキャッチするよりも、長いパケットでダブルビットエラーをキャッチする方が多少悪くなります。ダブルビットエラーが2番目に一般的な障害モードである場合（シングルビットエラーの後）、それは悪いことです。ただし、一部のデータを破損するものが多くのデータを破損する可能性がある場合、ダブルビットエラーを伴うCRCの劣った動作は問題ではない可能性があります。

3
supercat

CRCのサイズは、入力データのサイズではなく、CRCの一意性に関係していると思います。これは、CRCを計算している特定の使用法とアイテムの数に関連しています。

2
Samuel Neff

CRC-Nの素敵な「現実の世界」評価があります http://www.backplane.com/matt/crc64.html

CRC-32とファイルサイズの比較を使用しますが、チェックされる数十億のファイルで、一致するCRC-32とファイルサイズの衝突が発生することはありません。しかし、意図的に存在することを強制されていない場合、いくつか存在することを知っています。 （ハッキングされたトリック/エクスプロイト）

比較するときは、「データサイズ」もチェックする必要があります。正しいサイズ内で、一致するCRCと同じデータサイズの衝突はめったにありません。

一致を偽造するために意図的に操作されたデータは、通常、CRCがターゲットに一致するまで余分なデータを追加することによって行われます。ただし、その結果、一致しなくなったデータサイズになります。同じ正確なサイズのブルートフォース、またはランダムなデータ、またはシーケンシャルなデータを循環させようとすると、実際の狭い衝突率が残ります。

また、使用される数式の一般的な制限、および切り捨てられて切り取られる浮動小数点値に依存するビット/バイトおよび10進システムの使用制限によって、データサイズ内で衝突を起こすこともあります。

大きくなることを考えたいのは、「オリジナル」として「確認」できない衝突が多く見られるようになるときです。 （両方が同じデータサイズである場合、および（逆方向にテストされた場合、一致するCRCがあります。リバース/バイトまたはリバース/ビット、またはビットオフセット）

いずれにせよ、索引付けのための比較の簡単な形式のためだけに、比較の唯一の形式として決して使用すべきではありません。

CRC-8を使用してインターネット全体のインデックスを作成し、すべてをNカテゴリのいずれかに分割できます。あなたはそれらの衝突を望んでいます。さて、事前にソートされたもので、N-ディレクトリの1つをチェックするだけで、「ファイルサイズ」、「逆CRC」、またはその小さなデータセットに対して実行できる他の比較を高速に検索できます。 ..

同じデータのblobでCRC-32を前後に実行することは、CRC-64を一方向で使用するよりも信頼性があります。 （または、MD5、その点で。）

2
JD_Mortal

CRCは、メッセージの長さに合わせて選択する必要があります。CRCのサイズの問題だけではありません。 http://www.ece.cmu.edu/~ koopman/roses/dsn04/koopman04_crc_poly_embedded.pdf

2
starblue