netdev - Re: HalfSipHash Acceptable Usage

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]

Date:   Wed, 21 Dec 2016 17:37:12 +0100
From:   "Jason A. Donenfeld" <Jason@...c4.com>
To:     George Spelvin <linux@...encehorizons.net>
Cc:     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>,
        Eric Dumazet <eric.dumazet@...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>,
        "Theodore Ts'o" <tytso@....edu>,
        Vegard Nossum <vegard.nossum@...il.com>
Subject: Re: HalfSipHash Acceptable Usage

Hi George,

On Wed, Dec 21, 2016 at 4:55 PM, George Spelvin
<linux@...encehorizons.net> wrote:
> Actually, DJB just made a very relevant suggestion.
>
> As I've mentioned, the 32-bit performance problems are an x86-specific
> problem.  ARM does very well, and other processors aren't bad at all.
>
> SipHash fits very nicely (and runs very fast) in the MMX registers.
>
> They're 64 bits, and there are 8 of them, so the integer registers can
> be reserved for pointers and loop counters and all that.  And there's
> reference code available.
>
> How much does kernel_fpu_begin()/kernel_fpu_end() cost?

In my experience, these functions are only worth calling when
processing more significant amounts of data. I don't have any
benchmarks, but when I _remove_ all of these calls in a kernel,
accelerated crypto gets noticeably faster (until the system crashes).
We can measure it, though.

By the way, if somehow SipHash becomes acceptably fast on x86, would
you consider HalfSipHash for hash tables to be no longer needed? Or do
you suspect that HalfSipHash will always be faster even on, say,
32-bit ARM.

Jason