Siphash is secure in the same sense as AES, HMAC and a CSPRNG: seeing many consecutive values does reveal the key and does not allow predicting the next value.
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
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).
"Order-exposure and timing attacks" -- which types of attacks against SipHash do you have in mind? Could you elaborate, instead of your misinformed hand-waving?
Isn't that the case for every cryptographic primitive? I mean, that's sort of the point of private keys, yes? Once you have the key, you can decrypt AES ciphertext, create signatures with RSA, and forge valid MAC tags.
Not sure what point you're making here.
Can you explain how to conduct "order-exposure and timing attacks" against SipHash? The page you link describes how to conduct "poking into memory", which is outside of the threat model.