CRCはMD5 / SHA1よりも適切に使用できるのはいつですか?


130

MD5やSHA1などの最新のハッシュ関数ではなく、エラー検出にCRCを使用するのが適切なのはいつですか?前者は組み込みハードウェアに実装する方が簡単ですか?

回答:


114

CRCは、ネットワーク干渉、回線ノイズ、歪みなどから発生する可能性のあるデータのランダムエラーを検出するために適切に機能します。

CRCはMD5やSHA1よりも計算がはるかに簡単です。MD5のようなハッシュ関数を使用すると、ランダムなエラー検出にはおそらくやり過ぎです。ただし、任意の種類のセキュリティチェックにCRCを使用すると、MD5などのより複雑なハッシュ関数よりもはるかに安全性が低くなります。

そしてはい、CRCは組み込みハードウェアに実装する方がはるかに簡単です。これをICでパッケージ化したさまざまなソリューションを入手することもできます。


1
@gili:dwordを常にxorするだけで、結果として1つのdwordを取得できます。
ブリンディ2009年

2
@ダスティン:答えは完全に正しいですが、「CRCは計算上はるかに効率的」から「CRCは計算上はるかに簡単」に変更することを検討してください。MD5 / SHA-1アルゴリズムは複雑ですが、実際には「非効率」なIMOではありません。
コクシー

1
@coxymla正解です。私が使用すべきだった単語は「非効率」ではなく「複雑」です。ありがとう!
2010年

27
長いハッシュを32ビットに減らすには、最初の32ビットを使用します。
orip

1
セキュリティが目標である場合は、を絶対に使用しないMD5SHA-1ください。また、回避する必要がありますSHA-2。いくつかのバリアントをお勧めします。
Peter

33

CRCは、データの意図しない変更に対して設計されています。つまり、意図しないエラーを検出するのに適していますが、データが悪意を持って処理されていないことを確認する方法としては役に立ちません。

参照してくださいこれを


この回答のリンクの最も重要な部分:「(...)2048ビットCRCでも128ビットMD5よりも暗号的にはるかに安全ではない」
Marc.2377

3
答えは正しいですが、MD5とSHA1は現在、同じレベルのセキュリティにあります。つまり、意図しないエラーを検出する場合にのみ有効です。
Piskvorは、

21

ハッシュテーブルのCRCハッシュがいかに不適切であるを示す調査結果を見つけました。また、アルゴリズムの実際の特性についても説明します。この調査には、他のハッシュアルゴリズムの評価も含まれているので、参考にしてください。

ハッシュのCRCに関する関連する結論:

CRC32はハッシュテーブルの使用を意図したものではありません。これをこの目的で使用する十分な理由はありません。使用しないことをお勧めします。CRC32を使用する場合は、キーオクテットが入力される側とは反対側の端からハッシュビットを使用することが重要です。どちらの端がどちらであるかは、特定のCRC32実装によって異なります。CRC32を「ブラックボックス」ハッシュ関数として扱わないでください。また、CRC32を汎用ハッシュとして使用しないでください。アプリケーションの適合性を必ずテストしてください。

更新

サイトがダウンしているようです。インターネットアーカイブにはコピーを持っているのに。


リンクが壊れています。多分あなたは自分で説明を書くことができますか?そうでなければ答えは役に立たない。
2014年

さて、私は私の結論に結論を含めます。
Andre Luus 14年

奇妙なことに、ここのベンチマークによると、CRCは実際には速度と衝突の数の点でかなりうまくいきます。
ostrokach

確かに非常に興味深い。私は再びリンクした調査を見直す必要がありましたが、推測する必要がある場合は、テストの実装が異なるためであるに違いありません。決定を下さなければならなかった場合、私は研究からのアドバイスを求めます、それはより科学的に健全であるように見えます。
Andre Luus

何百万ものURLをハッシュした私の経験では、CRC64は8回衝突し、MD5は5回衝突しました。明らかにMD5の方が優れていましたが、CRC64は素晴らしく、はるかに高速で単純なハッシュでした。
J.ディメオ2017年

18

このPHPコードのすべての行を1.000.000ループで実行しました。結果はコメント(#)にあります。

hash('crc32', 'The quick brown fox jumped over the lazy dog.');#  750ms   8 chars
hash('crc32b','The quick brown fox jumped over the lazy dog.');#  700ms   8 chars
hash('md5',   'The quick brown fox jumped over the lazy dog.');#  770ms  32 chars
hash('sha1',  'The quick brown fox jumped over the lazy dog.');#  880ms  40 chars
hash('sha256','The quick brown fox jumped over the lazy dog.');# 1490ms  64 chars
hash('sha384','The quick brown fox jumped over the lazy dog.');# 1830ms  96 chars
hash('sha512','The quick brown fox jumped over the lazy dog.');# 1870ms 128 chars

私の結論:

  • http://en.wikipedia.org/wiki/Cyclic_redundancy_checkが必要で、セキュリティを気にしない場合は、「crc32b」を使用します。
  • セキュリティ層を追加する必要がある場合は、「sha256」以上を使用してください。

  • 「md5」または「sha1」は次の理由により使用しないでください。

    1. セキュリティを気にするときのいくつかのセキュリティ問題
    2. ハッシュ文字列が長く、CRCだけが必要な場合は「crc32b」よりも遅い

文字ではなくビットを意味します
esskar

あんまり。echo hash( 'crc32'、 '速い茶色のキツネが怠惰な犬を飛び越えた。'); "413a86af"をエコーし​​ます。これは8文字の文字列です。ところで、それはHEX形式で保存された32ビットの数値です。たとえば、「sha256」には256ビットのハッシュがあり、これもHEXとして格納され、64文字の長い文字列を提供します。
マーティン

45
これらの結果は非常にだまされています。これらのハッシュアルゴリズムが大規模なデータセット(の代わりに戦争と平和"The quick brown fox jumped over the lazy dog.")に適用される場合、MD5よりもはるかに高速なCRCがわかります。
ubiquibacon

1
MD5 / Sha1が正しい解決策である中間的なケース(ライブラリでの重複チェック)があります。敵が存在する可能性が非常に低いハッシュコリジョンを慎重に作成しているケースを処理する必要はありませんが、偶発的なコリジョンを処理する必要があります。そのため:ビットエラーと破損の検出:CRC32ライブラリでの衝突の検出:MD5 / SHA1敵対的アプリケーション:Sha256以上。もちろん、何十億ものエントリを持つライブラリがある場合、おそらくハッシュビットも増やす必要があります。
Dewi Morgan

PHP?ARMプラットフォームでは、埋め込みコード、16 MHz、46バイトのCRC32、おそらく12マイクロ秒。それはハードウェア支援を持っています。ハードウェア支援のAESでも数百倍遅くなります。支援なしのルックアップテーブルCRCは、依然として約50マイクロ秒で到着するはずです。
ilgitano 2018


9

それはすべて、要件と期待に依存します。

これらのハッシュ関数アルゴリズムの簡単な違いは次のとおりです。

CRC(CRC-8 / 16/32/64)

  • ではない暗号ハッシュアルゴリズムで(巡回冗長検査に基づく線形関数を使用しています)
  • 9、17、33、または65ビットを生成できます
  • 暗号化を保証しないため、暗号化の目的で使用することを意図していない、
  • 2006年には簡単に元に戻せるため、デジタル署名での使用には不適切は。
  • 暗号化の目的には使用しないでください。
  • 異なる文字列が衝突を発生させる可能性があります。
  • 1961年に発明され、イーサネットや他の多くの標準で使用され、

MD5

  • 暗号化ハッシュアルゴリズムです。
  • 128ビット(16バイト)のハッシュ値(32桁の16進数)を生成する
  • 暗号化ハッシュですが、セキュリティを心配する場合は非推奨と見なされます。
  • 同じMD5ハッシュ値を持つ既知の文字列があります
  • 暗号化の目的で使用でき、

SHA-1

  • 暗号化ハッシュアルゴリズムです。

  • メッセージダイジェストと呼ばれる160ビット(20バイト)のハッシュ値を生成します

  • これは暗号化ハッシュであり、2005年以降は安全とは見なされなくなりました。

  • 暗号化の目的で使用でき、

  • sha1衝突の例が見つかりました

  • 1993年に最初に公開され(SHA-0として)、1995年にSHA-1として公開されました

  • シリーズ:SHA-0、SHA-1、SHA-2、SHA-3、

    2005年には、暗号解読は、それが継続的な使用のために安全ではない十分かもしれ示唆SHA-1への攻撃見つけたので要約すると、SHA-1を使用することは、もはや、よく資金を供給相手に対して安全と見なされていないシュナイアーを。US NISTは、連邦機関は衝突耐性を必要とするアプリケーションではSHA1-1の使用を停止し、2010 NIST以降はSHA-2を使用する必要があることを推奨しています。

したがって、ファイルの整合性をチェックするための(破損に対して)シンプルで迅速なソリューションを探している場合、またはパフォーマンスの観点から単純なキャッシュを目的としている場合は、CRC-32を検討できます。 MD5。ただし、衝突の可能性を回避するために(安全で一貫性のある)プロフェッショナルアプリケーションを開発している場合は、SHA-2以上(SHA-3など)を使用してください。

パフォーマンス

PHPでの簡単なベンチマークテスト:

# Testing static text.

$ time php -r 'for ($i=0;$i<1000000;$i++) crc32("foo");'
real    0m0.845s
user    0m0.830s
sys     0m0.008s

$ time php -r 'for ($i=0;$i<1000000;$i++) md5("foo");'
real    0m1.103s
user    0m1.089s
sys     0m0.009s

$ time php -r 'for ($i=0;$i<1000000;$i++) sha1("foo");'
real    0m1.132s
user    0m1.116s
sys   0m0.010s

# Testing random number. 

$ time php -r 'for ($i=0;$i<1000000;$i++) crc32(rand(0,$i));'
real    0m1.754s
user    0m1.735s
sys     0m0.012s\

$ time php -r 'for ($i=0;$i<1000000;$i++) md5(rand(0,$i));'
real    0m2.065s
user    0m2.042s
sys     0m0.015s

$ time php -r 'for ($i=0;$i<1000000;$i++) sha1(rand(0,$i));'
real    0m2.050s
user    0m2.021s
sys     0m0.015s

関連:


8

あなたが守ろうとしていることは何であるかは言いません。

CRCは、悪意のあるシステムの変更を防止するのではなく、偶発的なデータ破損のチェックとして組み込みシステムでよく使用されます。CRCが役立つ場所の例は、システムの初期化中にEPROMイメージを検証して、ファームウェアの破損を防ぐことです。システムブートローダーは、アプリケーションコードのCRCを計算し、コードの実行を許可する前に格納された値と比較します。これにより、プログラムの偶発的な破損やダウンロードの失敗の可能性を防ぎます。

CRCを同様の方法で使用して、FLASHまたはEEPROMに保存されている構成データを保護することもできます。CRCが正しくない場合、データに無効のフラグが付けられ、デフォルトまたはバックアップデータセットが使用されます。デバイスの障害のため、または構成データストアの更新中にユーザーが電源を切断した場合、CRCは無効になる可能性があります。

ハッシュは、複数のビットエラーのあるCRCよりも破損を検出する可能性が高いというコメントがあります。これは真実であり、16ビットまたは32ビットのCRCを使用するかどうかの決定は、使用されている破損したデータブロックの安全性の結果と、1の2 ^ 16または2 ^ 32の確率を正当化できるかどうかにかかっています。データブロックが有効であると誤って宣言されています。

多くのデバイスには、標準アルゴリズム用の組み込みCRCジェネレーターがあります。テキサスのMSP430F5Xシリーズは、CRC-CCITT標準のハードウェア実装を備えています。


6

CRC32はより高速で、ハッシュの長さは32ビットのみです。

すばやく簡単なチェックサムが必要な場合に使用します。CRCはイーサネットで使用されます。

より高い信頼性が必要な場合は、最新のハッシュ関数を使用することをお勧めします。


5

計算リソースが非常に狭い場合(つまり、一部の埋め込み環境)、または多くの出力値を格納/転送する必要があり、スペース/帯域幅が狭い場合にのみCRCを使用します(CRCは通常32ビットであり、MD5出力は128ビットで、SHA1 160です。ビット、および最大512ビットの他のSHAバリアント)。

CRCは「偽造」が非常に簡単であるため、セキュリティチェックにCRCを使用しないでください。

(悪意のある変更の検出ではなく)偶発的なエラー検出の場合でも、ハッシュは単純なCRCよりも優れています。CRCが計算される単純な方法が原因で(およびCRC値が通常のハッシュ出力よりも通常短いため、可能な値の範囲がはるかに小さいため)、2つ以上のエラーがある状況では、 、1つのエラーが別のエラーをマスクするため、2つのエラーがあっても同じCRCになります。

つまり、まともなハッシュアルゴリズムを使用しない理由がない限り、単純なCRCは避けてください。


1
適切な多項式を使用している場合、CRCはすべての偶発的なデータ変更をキャッチします。正確に複数のビットが変更されると、1/2 ^ 32の変更が失われます。
ゲルハルト

また、適切な多項式を使用すると、バーストエラーなど、特定の一般的なクラスのすべてのエラーも検出できます。
erikkallen 2009年

質問が組み込みシステムに関するものであることを除いて、私はあなたの答えに同意します。小さな組み込みシステムでは、暗号化アルゴリズムのパフォーマンスに問題が生じる可能性があります。
クレイグマックイーン

絶対に反対だろう。CRCエラー多項式は、1,2,3,5を確実に検出できるように慎重に選択され、場合によっては11ビット程度までエラーをバーストできます。暗号化ハッシュは純粋に統計的であるため、大きなダイジェスト値を使用する必要があります。8-32ビットは、暗号ハッシュダイジェストとしては非現実的であり、CPUサイクルやゲートでは無意味に高価です。組み込みシステムで作業している場合は、間違いなく回答する必要はありません。CRCを使用しない唯一の時間は、インテリジェントな敵のシナリオに対処する必要がある場合です。
ilgitano 2018

5

最近、スマートなCRCの使用法に遭遇しました。著者jdupeのファイルの重複識別および除去ツール(人気のEXIFツールjheadの同じ作者)は、ファイルを最初に通過する間にそれを使用しています。CRCは各ファイルの最初の32Kで計算され、同じように見えるファイルをマークします。また、ファイルは同じサイズでなければなりません。これらのファイルは、完全なバイナリ比較を行うファイルのリストに追加されます。大きなメディアファイルのチェックを高速化します。


そのアプローチの1つの問題は、埋め込まれたCRC32が含まれているファイルで実行すると、結果のCRCがファイル内のデータから独立している可能性があります(データが変更されると、CRC32が変更され、違いがキャンセルされます)。CRC32を計算する前に簡単な方法でデータを変換すると、その問題を回避できます。
スーパーキャット2009年

1
@supercat-これが実際に問題であるとは本当に信じていません。ファイルにファイルの残りの部分のcrc32であるcrc32ヘッダーが含まれている場合、ファイルが更新されると、crc32ヘッダーの各ビットが約50%の確率で異なる可能性があります。ヘッダーの変更は、かなりランダムな分布に従う必要があります。これがどのようにしてCRC32(ヘッダー+データ)が常に同じになるか、またはファイルのデータ部分に依存しない方法を確認できません。
teratorn

@teratorn:特定のシード定数を使用して計算されたファイル全体のCRC32が常に他の定数値になるように計算された、末尾にCRC32があるファイルをいくつか見ました。これは、バイナリコードイメージのようなものではかなり一般的です。Acme 1000 DVDプレーヤーがファームウェアのアップグレードに固定サイズのコードイメージを使用し、すべてのコードイメージに特定のCRC32があることを期待している場合、さまざまなファイルのCRC32を計算するルーチンはAcme 1000の異なるコードイメージを区別できません。
スーパーキャット、

その場合のCRCのポイントは、ファイルが異なることをすばやく特定することです。CRCが同じ結果を返した場合、高価なバイナリ比較を実行する必要があるため、埋め込まれたCRCがアルゴリズムを壊すことはありません。CRCの最初のパスでファイルが同じである可能性が高いが、それらの多くはありそうにないため、一部のファイルがバイナリで比較されてしまうことがあり、カスタム多項式を使用することで回避できます。
ilgitano 2018

4

CRC32ははるかに高速で、ハードウェアサポートを備えている場合があります(Nehalemプロセッサなど)。本当に、あなたがそれを使う唯一の時間は、あなたがハードウェアとインターフェースしている場合、またはあなたが本当にパフォーマンスに厳しい場合です


4

基本から始めましょう。

暗号化では、ハッシュアルゴリズムは、ダイジェスト操作によって多くのビットをより少ないビットに変換します。ハッシュは、メッセージとファイルの整合性を確認するために使用されます。

すべてのハッシュアルゴリズムは衝突を生成します。衝突とは、いくつかの多くのビットの組み合わせが同じより少ないビット出力を生成する場合です。ハッシュアルゴリズムの暗号強度は、特定の入力に対して出力がどうなるかを個人が判断できないことによって定義されます。これは、正当なファイルと一致するハッシュでファイルを作成し、想定される整合性を損なう可能性があるためです。システムの。CRC32とMD5の違いは、MD5が生成するハッシュが大きくなり、予測が困難になることです。

メッセージの整合性を実装する場合、つまりメッセージが転送中に改ざんされていない場合、衝突を予測できないことは重要な特性です。32ビットのハッシュを記述することができます40億異なるメッセージ 40億異なるユニークなハッシュを使用するか、ファイルを。40億と1つのファイルがある場合、1回の衝突が保証されます。1 TBのビットスペースには、何十億もの衝突の可能性があります。私が攻撃者であり、その32ビットハッシュがどうなるかを予測できる場合、ターゲットファイルと衝突する感染ファイルを作成できます。同じハッシュを持っています。

さらに、10 Mbpsの転送を行っている場合、パケットが破損してcrc32をバイパスし、宛先に沿って続行して実行される可能性は非常に低くなります。10mbpsで10個のエラー\秒を取得するとします。それを1 Gbpsに上げると、毎秒1,000エラーが発生します。毎秒最大1エクサビットに達すると、毎秒1,000,000,000エラーのエラー率になります。 1 \ 1,000,000だとします送信エラーの衝突率があるとします。つまり、100万分の1の送信エラーにより、破損したデータが検出されずに通過します。10 Mbpsでは、エラーデータが100,000秒ごと、または1日に1回送信されます。1 Gbpsでは5分に1回発生します。毎秒1エクサビットで、1秒間に数回話しています。

Wiresharkをポップオープンすると、通常のイーサネットヘッダーにCRC32があり、IPヘッダーにCRC32があり、TCPヘッダーにCRC32があることがわかります。これは、上位層のプロトコルの機能に加えて、たとえば、IPSECは、上記に加えて、整合性チェックにMD5またはSHAを使用する場合があります。一般的なネットワーク通信にはエラーチェックのいくつかのレイヤーがあり、それらは10mbps未満の速度で時々失敗します。

巡回冗長検査(CRC)には、いくつかの一般的なバージョンといくつかの一般的でないバージョンがありますが、一般に、メッセージまたはファイルが転送中に破損した(マルチビットフリッピング)ときに通知するように設計されています。CRC32自体は、衝突率が原因で、大規模なスカラーエンタープライズ環境における今日の標準では、非常に優れたエラーチェックプロトコルではありません。平均的なユーザーのハードドライブは10万以上のファイルを持つことができ、会社でのファイル共有は数千万になることがあります。ファイルの数に対するハッシュスペースの比率が低すぎます。CRC32は実装が計算的に安価ですが、MD5はそうではありません。

MD5は、意図的な衝突の使用を停止して、悪意のあるファイルを無害に見えるように設計されています。ハッシュスペースが十分にマッピングされており、攻撃が発生したり、衝突が予測されたりする可能性があるため、安全ではないと考えられています。SHA1とSHA2は、ブロックの新しい子供です。

Md5は、マルチギガバイトのファイルやマルチテラバイトのファイルをすばやく作成し、一般的なOSでの使用とCRC32のサポートに重ねることができるため、ファイル検証で多くのベンダーによって使用され始めています。今後10年以内にファイルシステムがエラーチェックにMD5を使用し始めても驚かないでください。


弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.