netdev - Re: RFC: Established connections hash function

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20070328104505.GA18748@2ka.mipt.ru>
Date:	Wed, 28 Mar 2007 14:45:06 +0400
From:	Evgeniy Polyakov <johnpol@....mipt.ru>
To:	Andi Kleen <ak@...e.de>
Cc:	nikb@...master.com, netdev@...r.kernel.org
Subject: Re: RFC: Established connections hash function

On Wed, Mar 28, 2007 at 11:29:43AM +0200, Andi Kleen (ak@...e.de) wrote:
> > > But I think it can be mostly ignored.
> > 
> >     With all due respect, it cannot. An attacker with a small-sized botnet 
> > (which is ~250 hosts) can create chains that contain well in excess of 3000 
> > items. 
> 
> Most likely they can also easily generate enough latency data to crack any simple
> hash function then.

Jenkins hash is far from being simple to crack, although with some
knowledge it can be done faster.

SHA or something else is essentially the same, except it has different
set of rounds - we only hashes 3 32 bit values, so Jenkins result is
really good.

For the hash tables it is a good solution, but we can move further.
I created multidimensional trie with that problem in mind, but it looks
like right now it is not absolutely required solution - I will continue
to work on it to check if we can be faster than properly sized hash
table with additional trie allocation overhead, but likely I should not
force people include it as is, only for information I think.

> -Andi

-- 
	Evgeniy Polyakov
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html