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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <20070323083331.GB7193@2ka.mipt.ru>
Date:	Fri, 23 Mar 2007 11:33:32 +0300
From:	Evgeniy Polyakov <johnpol@....mipt.ru>
To:	Eric Dumazet <dada1@...mosbay.com>
Cc:	David Miller <davem@...emloft.net>, nikb@...master.com,
	netdev@...r.kernel.org
Subject: Re: RFC: Established connections hash function

On Fri, Mar 23, 2007 at 09:17:19AM +0100, Eric Dumazet (dada1@...mosbay.com) wrote:
> You have a machine somewhere that allows 65536 concurrent connections 
> coming from the same IP address ?

Attached png file of botnet scenario:
1000 addresses from the same network (class B for example),
each one creates 1024 connections to the same static port.

Eric, I agree, that XOR hash is not perfect, and it should be changed,
but not blindly.

I perfectly know that hash function is not bijective, but it must have
good distribution. 
Function like this
int hash(u32 saddr, u16 sport, u32 daddr, u16 dport, u32 rand)
{
	return ((((rand ^ saddr ^ daddr)>>16)^(dport ^ sport)) >>8);
}

has even worse _distribution_, although you can not predict its end
result due to random value, and attacker will not try to do it.

-- 
	Evgeniy Polyakov

Download attachment "jhash_botnet.png" of type "image/png" (5481 bytes)