[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHmME9oCfCwAq1qP09uAN6vvakh4wXDMHunsL9D7W_LDeN_OQQ@mail.gmail.com>
Date: Wed, 21 Dec 2016 15:42:33 +0100
From: "Jason A. Donenfeld" <Jason@...c4.com>
To: Eric Dumazet <eric.dumazet@...il.com>
Cc: George Spelvin <linux@...encehorizons.net>,
"Theodore Ts'o" <tytso@....edu>, Andi Kleen <ak@...ux.intel.com>,
David Miller <davem@...emloft.net>,
David Laight <David.Laight@...lab.com>,
"Daniel J . Bernstein" <djb@...yp.to>,
Eric Biggers <ebiggers3@...il.com>,
Hannes Frederic Sowa <hannes@...essinduktion.org>,
Jean-Philippe Aumasson <jeanphilippe.aumasson@...il.com>,
kernel-hardening@...ts.openwall.com,
Linux Crypto Mailing List <linux-crypto@...r.kernel.org>,
LKML <linux-kernel@...r.kernel.org>,
Andy Lutomirski <luto@...capital.net>,
Netdev <netdev@...r.kernel.org>,
Tom Herbert <tom@...bertland.com>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Vegard Nossum <vegard.nossum@...il.com>
Subject: Re: HalfSipHash Acceptable Usage
Hi Eric,
I computed performance numbers for both 32-bit and 64-bit using the
actual functions in which talking about replacing MD5 with SipHash.
The basic harness is here [1] if you're curious. SipHash was a pretty
clear winner for both cases.
x86_64:
[ 1.714302] secure_tcpv6_sequence_number_md5# cycles: 102373398
[ 1.747685] secure_tcp_sequence_number_md5# cycles: 92042258
[ 1.773522] secure_tcpv6_sequence_number_siphash# cycles: 70786533
[ 1.798701] secure_tcp_sequence_number_siphash# cycles: 68941043
x86:
[ 1.635749] secure_tcpv6_sequence_number_md5# cycles: 106016335
[ 1.670259] secure_tcp_sequence_number_md5# cycles: 95670512
[ 1.708387] secure_tcpv6_sequence_number_siphash# cycles: 105988635
[ 1.740264] secure_tcp_sequence_number_siphash# cycles: 88225395
>>> 102373398 > 70786533
True
>>> 92042258 > 68941043
True
>>> 106016335 > 105988635
True
>>> 95670512 > 88225395
True
While MD5 is probably faster for some kind of large-data
cycles-per-byte, due to its 64-byte internal state, SipHash -- the
"Sip" part standing "Short Input PRF" -- is fast for shorter inputs.
In practice with the functions we're talking about replacing, there's
no need to hash 64-bytes. So, SipHash comes out faster and more
secure.
I also haven't begun to look focusedly at the assembly my SipHash
implemention is generating, which means there's still window for even
more performance improvements.
Jason
[1] https://git.zx2c4.com/linux-dev/tree/net/core/secure_seq.c?h=siphash-bench#n194
Powered by blists - more mailing lists