問題タブ [adler32]

PHP で Adler32 ローリング ハッシュを実装しましたがord、文字列内のチャンターの整数値を取得するのが非常に遅い (私の開発マシンでは毎秒約 1MB) ため、このソリューションは 100MB 以上のファイルでは機能しません。

PHP の mhash 関数は、adler32 の非常に迅速な計算を取得できます (私の開発マシンでは毎秒 120MB)。ただし、mhash は adler32 のローリングの性質をサポートしていないようです。そのため、実際に変更された 2 バイトのハッシュを再計算するだけでなく、ローリング ウィンドウの移動に合わせてまったく新しい adler32 を計算する必要があります。

私は adler32 アルゴリズムに縛られていません。PHP で非常に高速なローリング ハッシュが必要なだけです。

Adler32 に頼るべきではないと聞きましたが、その理由をお聞きしたいと思います。

Adler32 のハッシュを信頼してはならないのはなぜですか? リバーシブルですか？それとも、実際のテキストを簡単に見ることができますか?

adler32 checksumのローリングバージョンを実装しています。

この回答は、私の数学を再確認するのに役立ちました。ただし、golang で正しく実装するのに苦労しています。

次のコードを書きました。

ランダムなデータで実行することを決定するまで、さまざまな入力でテストし、正常に機能しました。これが機能しないサンプルです（いくつか見つけました）。

私を困惑させているのは、Pythonの同じコードがこれらの入力で完全に機能することです:

念のため、これが Python で機能することの証明を含めます。Python チェックサムは、go チェックサムの非ローリング バージョンと一致することに注意してください (その部分は、go コア ライブラリから直接取得されます)。

問題のある他のすべてのサンプルで結果を調べたところ、チェックサムの最下位ビット (「a」ビット) を決して間違えていないことがわかりました。また、エラーは一貫して同じで、 に等しくなり0xe10000ます。go が uint32 整数の剰余演算を処理する方法の特殊性が、この原因であると思われます。

何が起こっているのか、コードを修正するにはどうすればよいですか?

ネイティブ HW 関数を備えたマイクロコントローラーを使用して、多項式を自由に定義できるメモリのチャンクから CRC32 ハッシュを計算しています。システムには、16 ビットや 8 ビットなど、CRC のビット長が異なるさまざまなデータ リンクがあることがわかりました。これにはハードウェア エンジンを使用する予定です。

オンライン ツールを使用した簡単なテストでは、8 ビット CRC と同じ結果を持つ 32 ビット多項式を見つけることができると結論付けました。例:

• 8ビットエンジンとpoly 0xb7で「サンプル文字列」をハッシュすると、結果は0x97になります
• 16ビットエンジンとpoly 0xb700で「サンプル文字列」をハッシュすると、結果は0x9700になります
• ...32 ビット エンジンと poly 0xb7000000 は、結果 0x97000000 を生成します (初期値がゼロ、最終 xor がゼロ、反射なし)

そのため、ポリゴンをゼロでパディングし、結果を右シフトするとうまくいくようです。しかし、32 ビット エンジンを 16 または 8 ビット エンジンとして動作させる一連のパラメータを「常に」見つけることは可能ですか? (poly、final xor、init val、inversions を含む)

より多くのコンテキストを提供し、「ネイティブ エンジンを使用しないでください」などの「バイパス回答」を防ぐには: 一般的な設計エラーが冗長な処理ノードに伝播するのを防ぐ必要がある、安全性が重要なシステムのシナリオがあります。そのための 1 つの解決策は、1 つのノードでソフトウェア ベースの CRC 計算を行い、そのペアでハードウェア ベースの CRC 計算を行うことです。