RetroSearch Browse

Mon Jan 2 19:53:09 CET 2012 · https://mail.python.org/pipermail/python-dev/2012-January/115240.html

On Mon, Jan 2, 2012 at 7:18 PM, Christian Heimes <lists at cheimes.de> wrote:
> Am 02.01.2012 06:55, schrieb Paul McMillan:
>> I think Ruby uses FNV-1 with a salt, making it less vulnerable to
>> this. FNV is otherwise similar to our existing hash function.
>>
>> For the record, cryptographically strong hash functions are in the
>> neighborhood of 400% slower than our existing hash function.
>
> I've pushed a new patch
> http://hg.python.org/features/randomhash/rev/0a65d2462e0c

It seems for 32-bit version you are using pid for the two constants.
Also, it's unclear why you even need to use a random constant for the
final pass, you already use random constant as an initial h1, and it
should be enough, no need to use for k1. Same for 128-bit: k1, k2, k3,
k4 should be initialized to zero, these are key data, they don't need
to be mixed with anything.

Also, I'm not sure how portable is the always_inline attribute, is it
supported on all compilers and all platforms?

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2012-January/115240.html below:

[Python-Dev] Hash collision security issue (now public)