Subject: Re: Extensible hashing and RCU

From: Eric Dumazet <[email-masked]>
Date: Tue, 20 Feb 2007 17:38:19 +0100

On Tuesday 20 February 2007 17:20, Evgeniy Polyakov wrote:
> On Tue, Feb 20, 2007 at 05:08:12PM +0100, Eric Dumazet ([email-masked]) 
wrote:
> > > Adding XOR with constant value does not change distribution.
> > > Variable salt will end up with differnet buckets for the same flow.
> > > It is forbidden - it is not the situation created for passwd/des
> > > decades ago.
> >
> > Adding a random hint to jhash (random value picked at boot time, not
> > known by attacker) permits to have a secure hash table : An attacker
> > cannot build an attack to fill one particular hash chain.
> >
> > See net/ipv4/route.c (function rt_hash_code()) to see how its used for
> > route cache.
>
> It is secrecy, not security - attacker will check the source and find
> where constant per-boot value is added and recalculate attack vector -
> we all were college students, it would be even more fun to crack.
>
> In that regard Jenkins ahsh and XOR one have _exactly_ the same attack
> vector, only Jenkins is a bit more sophisticated. I even think that
> example in rt_hash_code() will endup with heavy problems when one of the
> addresses is constant - my tests show problem exactly in the case of
> jhash_2words() with random third parameter and constant one of the first
> like in rt_hash_code().

Please define heavy problem.

On most hosts, with one NIC, one IP address, most entries in cache have the 
same address (IP address of eth0 or localhost). It just works.

Last time I checked, the 2^21 route cache I am using was correctly filled, 
thanks to jhash.

Again, the random value is 32bits. If jhash happens to be cracked by your 
students, we just put md5 or whatever in...

You can call it secrecy or whatever, fact is : it's just working, far better 
than XOR previous hash function.