衝突チェックなしのハッシュマップ
数日前、私は 楽しい事実 を発見しました。これは、総当たりを使用して256ビットハッシュの衝突を見つけることは、太陽系では物理的に不可能です。
そのため、ハッシュマップで優れた（均一な）256ビットハッシュを使用するとどうなるでしょうか。キーハッシュが誤って一致することは決してないので、ハッシュのみを保存するためにキーの実際の値を取り除くことができると考えることができます。
- スペース効率が良いでしょうか？ （キーの値はなく、ハッシュのみ）
- 高速でしょうか？ （衝突チェックはありませんが、通常より大きなハッシュ）
- 安全でしょうか？ （統計的に）
- 誰かがこれをしましたか？
はい、バケット数は2 ^ 256よりもはるかに少ない可能性があります。目標は、ハッシュを計算し、バケットを見つけて、実際の値チェックなしで、完全な256ビットハッシュのみを使用してバケット内の実際の値を見つけることです。たとえば、キーが文字列であるハッシュマップでは、等価性の確認ができないため、実際のバイト比較や大きなキーストレージの可能性はありません。
2 ^ 256の組み合わせを無視することがたくさんあるようです。スケールを示すために、既知の宇宙の推定原子数は10 ^ 78から10 ^ 82の間で、およそ2 ^ 260から2 ^ 270です。人類はおそらくすべての可能な256ビットの数値を生成しません。
はい、量子コンピューターは一瞬で衝突を見つけることができます。しかし、将来の暗号の安全性は重要ではありません。重要なのは、アプリケーションでの内部使用のためのインメモリ、標準ライブラリグレードコレクションの簡素化です。
はい、可能です。 [〜＃〜] zfs [〜＃〜] の詳細を調べて、このアイデアを使用するデプロイ済みの本番品質のシステムを探します。 ZFSでは、格納されるデータはすべて暗号化された256ビットハッシュでハッシュされ、システムに存在することがわかっている既存のデータと一致する場合は、同じデータ、およびディスク上の2つのブロックはマージの候補と見なされます。これは、最近アクセスしたブロックの大部分のハッシュテーブルを保持するのに十分なRAM（または、より現実的には、高速SSDスペース）がある限り、複製されたコピーを保存できることを意味します複製のために追加のスペースを必要としないファイル同じシステムもスナップショットを提供するために使用されます。
ファイルシステムには便利ですが、メモリへのアクセスにはコストがかかる（つまり、ディスクアクセスのレイテンシが原因である）非常に大きなオブジェクトに対しては非常に優れたアプローチであるため、メモリ内ストレージにはあまり役立ちません。高速アクセスの小さなオブジェクトの場合、小さなハッシュを計算し、ハッシュの衝突が発生したときに詳細にチェックする方が簡単です。これは、このような操作のハッシュ関数がmuchZFSの信頼性を高めるために必要な大きな暗号化ハッシュよりも速く、結果を保存するために必要なメモリが少なくて済みます。
そうです、そのような大きなハッシュ空間で衝突がほとんど発生しないハッシュ関数です。ただし、ハッシュテーブルは特定の目的でハッシュ関数を使用します。つまり、ハッシュテーブルエントリを特定のビンにマッピングします。これは通常、モジュロ演算、つまりbucket = hash(key) % n_bucketsを使用して行われます。 2のべき乗サイズのテーブルの場合、これはハッシュの上位ビットをマスクすることで非常に効率的に行うことができます。
そのため、ハッシュテーブルは、ハッシュコリジョンについては、バケットコリジョンについてほど気にしません。または別の見方をすると、一部のハッシュ関数を直接使用しませんが、そのハッシュ関数はバケットの数を法としています。
このため、ハッシュ空間が大きいハッシュ関数は無意味であり、ほぼすべてのビットがマスクされます。 256バケットのハッシュテーブルの場合、必要なのは8ビットだけで、それ以上は無駄になります。
ハッシュテーブルのビット数が非常に少ない場合、どのようにしてセキュリティで保護できますか？特に高速な（暗号化されていない）ハッシュ関数の場合、衝突を事前に計算することができます。攻撃者がこれらの衝突要素をハッシュテーブルにフィードした場合（クエリ文字列パラメーターをWebアプリケーションに入力した場合など）、それらは同じバケットにマップされるため、O(1)ハッシュのルックアップが低下します。リンクされたリストのテーブルへのテーブル：O（n）これは通常、ハッシュ関数をプロセスごとまたはテーブルごとのソルトでパラメーター化することによって防止されます。ソルトは攻撃者に知られていないため、共謀を事前に計算することはできません。
適切なハッシュアルゴリズムを使用すると、少なくとも一部のシナリオでは、アイデアが機能する可能性があります。特殊なアプリケーションの場合、それは貴重なパフォーマンス上の利点を持つことができます。ただし、ハッシュアルゴリズムの品質は非常に重要です。他の回答やコメントでは、GitやZFSのような、等しいハッシュは等しいオブジェクトを意味すると想定しているソフトウェアについて言及しています。彼らは既知のアルゴリズムで独自のハッシュを行うので、これを回避できます。
これは、汎用のコレクションには当てはまりません。たとえば、Javaでは、すべてのクラスが独自のハッシュメソッドを提供し、HashMapは格納するオブジェクトにハッシュを委任します。衝突を引き起こす可能性のある悪いハッシュアルゴリズムをクラスが使用することは完全に合法です。実際、everyオブジェクトに対して同じハッシュコードを返すことは完全に合法です。ハッシュベースのコレクションのパフォーマンスは低下しますが、正しい結果が得られます。あなたの地図はそうではないでしょう。