From: "Jason A. Donenfeld" Subject: Re: [PATCH v3 1/3] siphash: add cryptographically secure hashtable function Date: Wed, 14 Dec 2016 23:56:41 +0100 Message-ID: References: <20161214035927.30004-1-Jason@zx2c4.com> <20161214184605.24006-1-Jason@zx2c4.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Cc: Netdev , kernel-hardening@lists.openwall.com, LKML , Linux Crypto Mailing List , Jean-Philippe Aumasson , "Daniel J . Bernstein" , Linus Torvalds , Eric Biggers , David Laight To: Tom Herbert Return-path: In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org List-Id: linux-crypto.vger.kernel.org Hey Tom, On Wed, Dec 14, 2016 at 10:35 PM, Tom Herbert wrote: > Those look good, although I would probably just do 1,2,3 words and > then have a function that takes n words like jhash. Might want to call > these dword to distinguish from 32 bit words in jhash. So actually jhash_Nwords makes no sense, since it takes dwords (32-bits) not words (16-bits). The siphash analog should be called siphash24_Nqwords. I think what I'll do is change what I already have to: siphash24_1qword siphash24_2qword siphash24_3qword siphash24_4qword And then add some static inline helpers to assist with smaller u32s like ipv4 addresses called: siphash24_2dword siphash24_4dword siphash24_6dword siphash24_8dword While we're having something new, might as well call it the right thing. > Also, what is the significance of "24" in the function and constant > names? Can we just drop that and call this siphash? SipHash is actually a family of PRFs, differentiated by the number of SIPROUNDs after each 64-bit input is processed and the number of SIPROUNDs at the very end of the function. The best trade-off of speed and security for kernel usage is 2 rounds after each 64-bit input and 4 rounds at the end of the function. This doesn't fall to any known cryptanalysis and it's very fast.