Re: [PATCH v3 1/3] siphash: add cryptographically secure hashtable function

From: Tom Herbert
Date: Wed Dec 14 2016 - 18:14:10 EST

On Wed, Dec 14, 2016 at 2:56 PM, Jason A. Donenfeld <Jason@xxxxxxxxx> wrote:
> Hey Tom,
> On Wed, Dec 14, 2016 at 10:35 PM, Tom Herbert <tom@xxxxxxxxxxxxxxx> 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.
Yeah, that's a "bug" with jhash function names.

> 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.
I'm confused, doesn't 2dword == 1qword? Anyway, I think the qword
functions are good enough. If someone needs to hash over some odd
length they can either put them in a structure padded to 64 bits or
call the hash function that takes a byte length.

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

I'd still drop the "24" unless you really think we're going to have
multiple variants coming into the kernel.