Oh my. It's trivial to brute force SipHash to attack hash tables with a known seed. It's part of my hash table flood test for cperl.

Timings:

   BITS SIZE       TIME
   8  - 255        0.003s
   9  - 511        0.006s
   10 - 1023       0.033s
   11 - 2047       0.12s
   12 - 4095       0.45s
   13 - 8191       1.82s
   14 - 16383      7.6s
   15 - 32767      31s
   16 - 65535      2m2s
   18 - 262143     4m3s 23770

18-30 bit: ~4m for an attackable subset (linear time). The typical size in a kernel is 13bit.

The only SipHash security you get is seed hiding. Once you got it, it's insecure. You get the seed by various means, usually by poking into memory or by solving via order-exposure and timing attacks. This commit doesn't mention anything of it, because it followed the flawed siphash chapter 6, which only knows about chained hash tables.

So far only the linux kernel, glibc and java were the only immune hash tables to such nonsense. Now only java and glibc is remaining. I should have done that CCC talk this year about the disturbing siphash security theatre out there.

Thanks god the kernel still uses primes, so you need a full 32bit attack. But with this commit message I fear this will erode also to power of 2 sooner or later to use a simple bit test instead of mod (or the mult. trick).