2016-10-12 4 views
0

デバイスにデータを送信したいので、一貫性を確認する必要があります。攻撃者は存在しません。ハードウェア障害のみが存在する可能性があります。ハッシュするデータの最大量は「安全」ですか?

私の場合のMaximmumデータサイズは約256kBになります。

私は小さなフットプリントアルゴリズムと小さなハッシュサイズに興味があります。 CRC8、CRC16、CRC32、MD5、SHA1のようなものも使用できます。 SHA2ハッシュは私のためにとても大きいです。

実用的なデータサイズ制限の一般的なルールはありますか?

答えて

0

あなたのチャネルのエラー特性と、アプリケーションで許容される偽陽性率は何かを知る必要があります。どのくらいの頻度でエラーが発生しますか?変更されたビット数の分布は何ですか?あなたは時折シングルビットを反転させるか、エラーがあるときにたくさんのビットを反転させるか、メッセージ全体を混乱させますか?フリップされたビットが互いに接近している、すなわちエラーがバースト的に発生しているか?

通常、暗号化ハッシュを使用しません。これは、CRCと比較して計算するために費やされる時間が増えるため、利点がありません。 xxhashファミリのようなCRCやその他のハッシュを使用する必要があります。彼らは非常に高速であり、偽陽性を起こす可能性は低いです。 CRCは、エラーのバースト、すなわちいくつかの隣接する、またはほぼ隣接するビットフリップに対して保護する特別な特性を有する。

+0

私は数字がありません。私は、ハードウェアのエラーはほとんど起こりそうもないと言うことができます。それはちょうど反転することができますが、いくつかのまれなケースでは、それは完全なごみになることができます。私はxxhashを知らなかった、それはinterrestingと聞こえる。 – j123b567

+0

xxHashでは、あなたが私に必要なものである[SMHasher](https://github.com/aappleby/smhasher)ツールを指摘しました。 – j123b567

0

いいえsha1ハッシュは、すべての目的と目的に対してグローバルに一意であり、アルゴリズムは非常に大きな入力に対しては分解しません。 1ビットを変更すると、ハッシュが変更されるはずです。

+0

私は "birthday problem"のように、CRC8で257の異なるファイルを処理することを意味します。同じCRCを持つ2つのものが100%存在します。一方、暗号化ハッシュは非常に遅く、ハッシュが非常に大きい(sha1の場合は20バイト)。だから私はいくつかの黄金の意味が必要です。 – j123b567

+0

アルゴリズムがどれほど強いかは関係ありません。メッセージ(またはデータ)文字列がエラーチェック文字列よりも長い場合は、正しく記述したように、メッセージ文字列をエラーチェック文字列に重複してマッピングするケースが発生します。 – ysap

関連する問題