Можно ли безопасно использовать zlib.crc32 или zlib.adler32 для маскировки первичных ключей в URL?

Question

В Django Design Patterns автор рекомендует использовать zlib.crc32 для маскировки первичных ключей в URL-адресах. После некоторого быстрого тестирования я заметил, что crc32 выдает отрицательные целые числа примерно половину времени, что кажется нежелательным для использования в URL. zlib.adler32 не производит негативов, но описывается как «слабее», чем CRC .

1. Безопасен ли этот метод (CRC или Adler-32) для использования в URL в качестве альтернативы первичному ключу? (т. е. безопасен ли он от столкновений?)
2. Является ли «более слабый» Адлер-32 удовлетворительной альтернативой для этой задачи?
3. Как, черт возьми, ты это изменил ?! То есть как вы определяете исходный первичный ключ из контрольной суммы?

Answer 1

Проблема не в хешировании значения. Проблема заключается в сопоставлении хэша с ключом. Даже если есть столкновения, вы всегда можете увеличивать их до тех пор, пока не достигнете неиспользованного хэша.

Причины хеши используются, например, для аутентификация заключается в том, что уже есть ключ (например, имя пользователя), который можно использовать для поиска соответствующей записи. В этот момент становится просто вопросом сравнения данного хеша с сохраненным хешем. Если вместо этого вы используете хэш для маскировки ключа, то это будет сложнее, чем просто сравнивать его. Однако, превращение самого хэша в ключ решит эту проблему.

Answer 2

32-битное значение CRC можно интерпретировать как целое число без знака.

Answer 3

При дальнейшем исследовании это кажется очень плохой идеей:

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

Это 10 240 коллизий в 20 000 000 первичных ключей.