linux-kernel - [RFC] Use of SipHash and HalfSipHash for Hashtables and PRF

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>] [day] [month] [year] [list]

Date:   Tue, 10 Jan 2017 18:03:07 +0100
From:   "Jason A. Donenfeld" <Jason@...c4.com>
To:     LKML <linux-kernel@...r.kernel.org>,
        kernel-hardening@...ts.openwall.com
Cc:     Jean-Philippe Aumasson <jeanphilippe.aumasson@...il.com>
Subject: [RFC] Use of SipHash and HalfSipHash for Hashtables and PRF

Hi all,

In this case, by "RFC" I actually mean "request for commits". No
comments, please. :)

David Miller's net-next tree now has my SipHash patchset, which adds
SipHash to the kernel for all sorts of interesting uses. The first two
uses include syncookies and secure sequence numbers. Future uses
include hashtable lookup functions and other types of short MAC uses.
This message is an invitation to start switching certain interfaces
over to SipHash, if the use improves either performance or security,
or perhaps both.

So, what's the deal?

SipHash takes two inputs:
- A randomly generated 16-byte longterm secret key, generated via
get_random_bytes or get_random_once.
- Some variable length input.
SipHash then spits out:
- A 64-bit psuedo-random number.

Documentation and usage examples are in this document:
https://git.kernel.org/cgit/linux/kernel/git/davem/net-next.git/plain/Documentation/siphash.txt

If you have a hashtable that takes input from sources outside the
kernel, consider using SipHash. If you're generating deterministic
random bytes based on some key, consider using SipHash. If you're just
curious, consider using SipHash. I merely say "consider" using it,
because there are many cases in which SipHash will _not_ make sense,
so the result of such consideration will be a clear "no thanks". But
perhaps in other cases will indeed be useful, so your consideration
may very well be worthwhile. If you have any questions about it, don't
hesitate to inquire, and if you're at all uncertain about whether or
not your patch using it is correct, put me in the CC and I'll give my
2¢.

Jason