1

Django Design Patternsでは、著者は zlib.crc32 を使用して URL の主キーをマスクすることを推奨しています。いくつかの簡単なテストの後、crc32 が約半分の時間で負の整数を生成することに気付きました。これは URL での使用には望ましくないと思われます。zlib.adler32 はネガを生成するようには見えませんが、 CRC よりも「弱い」と説明されています。

  1. この方法 (CRC または Adler-32) は、主キーの代替として URL で安全に使用できますか? (つまり、衝突に対して安全ですか?)
  2. 「より弱い」Adler-32 は、このタスクの満足のいく代替手段ですか?
  3. 一体どうやってこれを逆にするの!? つまり、チェックサムから元の主キーをどのように判断するのでしょうか?
4

3 に答える 3

1

問題は値をハッシュすることではありません。問題は、ハッシュをキーにマッピングし直すことです。衝突があったとしても、未使用のハッシュにぶつかるまでいつでもインクリメントできます。

ハッシュが認証などに使用される理由は、適切なレコードを見つけるために使用できるキー（ユーザー名など）がすでに存在するためです。その時点で、与えられたハッシュを保存されたハッシュと比較するだけの問題になります。代わりにハッシュを使用してキーをマスクしている場合は、単に比較するよりも注意が必要です。ただし、ハッシュ自体をキーに変換すると、これは解決されます。

于 2010-04-09T21:11:53.323 に答える
1

32 ビット CRC 値を符号なし整数として解釈できます。

于 2010-04-09T20:35:53.050 に答える
1

さらに調査すると、これは本当に悪い考えのようです。

In [11]: s = set([zlib.crc32(str(x)) for x in xrange(20000000)])
In [12]: len(s)
Out[12]: 19989760
In [13]: 20000000 - len(s)
Out[13]: 10240

これは、20,000,000 個の主キーで 10,240 回の衝突です。

于 2010-04-09T21:03:18.300 に答える