2

元の md5 アルゴリズムが 128 ビットのハッシュを生成することは知っています。

ここでの Mark Adler のコメントに従って、適切な 64 ビット ハッシュを取得することに興味があります。OpenSSL を使用して md5 ベースの 64 ビット ハッシュを作成する方法はありますか? (md5は私のニーズには十分に見えます)。そうでない場合、OpenSSL ライブラリに実装された別のアルゴリズムで、md5 以上の品質でこの仕事を成し遂げることができますか (コースの長さを除く)?

4

1 に答える 1

2

「ハッシュの品質」はハッシュの長さに強く関係していると私は主張します。私の知る限り、OpenSSL には 64 ビット ハッシュ アルゴリズムがないため、最初に思いついたアイデアは単純で、おそらく価値のないものでした。

halfMD5 = md5.hiQuadWord ^ md5.lowQuadWord

最後に、crc64 のような適切な出力を持つアルゴリズムを使用するだけです。

確認するいくつかの crc64 ソース:


編集

一見、Jenkins は完璧に見えますが、これまでのところ、使いやすい C++ 実装を見つけようとしています。ところで、これはデータベースの重複チェックに非常に適したハッシュであるため、OpenSSL などの一般的なオープンソース ライブラリが API を提供していないのはなぜでしょうか? - 地下鉄

これは単に、OpenSSL がそもそも暗号ライブラリであり、適切な暗号特性を持つ大きなハッシュ値を使用しているという事実によるものかもしれません。

データ構造のハッシュアルゴリズムには、他にもいくつかの主要な目標があります。たとえば、ハッシュテーブルの優れた分散特性などです。小さなハッシュ値は、ゼロ、1 つ、または複数の (衝突する) 要素を含むバケットのリストへのインデックスとして使用されます。

したがって、ポイントは、衝突が処理されるかどうか、どのように、どこで処理されるかです。典型的な DBMS では、列のインデックスがそれら自体を処理します。

対応するコンテナ (マップまたはセット):

さらに、一意の制約により、等しいフィールド コンテンツの挿入が禁止されます。


たとえば、ファイルの内容 (プレーンテキスト、暗号化されていないアプリケーション) と、マッピングまたは整合性チェックのためのチェックサムまたはハッシュ値を含むテーブルがあります。新しいファイルを挿入します。そのために、ハッシュ値またはチェックサムを事前に計算し、ハッシュ値またはチェックサムがそれぞれ等しい既存のファイルを照会します。何も存在しない場合、衝突は発生せず、挿入は安全です。既存のレコードが 1 つ以上ある場合、正確に一致する可能性が高く、「実際の」競合が発生する可能性は低くなります。

  • 衝突を避ける必要がある場合は、ハッシュ列に一意の制約を追加し、コンテンツの不一致/衝突の可能性がある既存のレコードを再利用できます。ここでは、'Jenkins' のようなデータベースに適したハッシュ アルゴが必要です。

  • 衝突を処理する必要がある場合は、プレーンテキスト列に一意の制約を追加できます。crc のようなデータベースにあまり適していないチェックサム アルゴリズムは、レコード間の衝突に影響を与えず、検出する特定の種類の破損やその他の要件に従って選択できます。冒頭で述べたように、md5 の XOR されたクワッド ワードを使用することも可能です。

その他の考え:

  • プレーンテキスト列のインデックス/制約がマッピングを行う場合、任意のハッシュ値を使用してかなり高速なルックアップを実行し、潜在的な一致を見つけることができます。
  • マッピングに適したハッシュとチェックサムの両方を追加することを誰も止めません。
  • 一意の制約は、基本的に上記のハッシュ テーブルに似たインデックスも追加します。

要するに、64ビットハッシュアルゴリズムで何を達成したいかによって大きく異なります。

于 2013-03-17T10:03:50.407 に答える