netdev - Re: [PATCH 2/2] net: Use Toeplitz for IPv4 and IPv6 connection hashing

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: <20130923231752.GA2593@order.stressinduktion.org>
Date:	Tue, 24 Sep 2013 01:17:52 +0200
From:	Hannes Frederic Sowa <hannes@...essinduktion.org>
To:	Tom Herbert <therbert@...gle.com>
Cc:	davem@...emloft.net, netdev@...r.kernel.org,
	jesse.brandeburg@...el.com
Subject: Re: [PATCH 2/2] net: Use Toeplitz for IPv4 and IPv6 connection hashing

On Mon, Sep 23, 2013 at 03:44:51PM -0700, Tom Herbert wrote:
> diff --git a/include/net/inet6_hashtables.h b/include/net/inet6_hashtables.h
> index f52fa88..492a45b 100644
> --- a/include/net/inet6_hashtables.h
> +++ b/include/net/inet6_hashtables.h
> @@ -32,12 +32,28 @@ static inline unsigned int inet6_ehashfn(struct net *net,
>  				const struct in6_addr *laddr, const u16 lport,
>  				const struct in6_addr *faddr, const __be16 fport)
>  {
> +#if IS_ENABLED(CONFIG_IP_HASH_TOEPLITZ)
> +	struct {
> +		struct in6_addr saddr;
> +		struct in6_addr daddr;
> +		u16 sport;
> +		u16 dport;
> +	} input;
> +
> +        input.daddr = *laddr;
> +        input.saddr = *faddr;
> +        input.sport = htons(lport);
> +        input.dport = fport;
> +
> +        return toeplitz_hash((u8 *)&input, toeplitz_net, sizeof(input));
> +#else
>  	u32 ports = (((u32)lport) << 16) | (__force u32)fport;
>  
>  	return jhash_3words((__force u32)laddr->s6_addr32[3],
>  			    ipv6_addr_jhash(faddr),
>  			    ports,
>  			    inet_ehash_secret + net_hash_mix(net));
> +#endif

You seem to discard the secret inputs. This should make the hashing
considerable more insecure.

I always believed the reason for choosing linear feedback shift register
based hash functions was because of the parallelism a pure hardware
based implementation could exploit. This does not matter for the kernel.

IMHO jhash should be considered more secure just because of its wider usage.
;)

Greetings,

  Hannes

--
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