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

[Alexey Borzenkov]

On Mon, Jan 2, 2012 at 10:53 PM, Alexey Borzenkov <snaury at gmail.com> wrote:
> 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.

Sorry, sent too soon. What I mean is that you're initializing a pretty
big array of values when you only need a 32-bit value. Pid, in my
opinion might be too predictable, it would be a lot better to simply
hash pid and gettimeofday bytes to produce this single 32-bit value
and use it for h1, h2, h3 and h4 in both 32-bit and 128-bit versions.

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