3 ms·

Per that argument, AES is insecure because if I know the key, I can decrypt your messages and even fake a message with valid CMAC authentication tag. Siphash i

Per that argument, AES is insecure because if I know the key, I can decrypt your messages and even fake a message with valid CMAC authentication tag. 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.

wolf550e 10y ago
Too late to edit. I meant "does not reveal the key", of course.
rurban 10y ago
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).
- geofft 10y ago
  > usually by poking into memory or by solving via order-exposure and timing attacks. 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.
- zx2c4 10y ago
  "Poking into kernel memory" is not possible without a serious security vulnerability. That's not within this threat model. "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?
- tptacek 10y ago
  Since it's trivial to "brute force" any cryptographic construction given its key, I remain confused as to the point you're trying to make here.
- atoponce 10y ago
  > The only SipHash security you get is seed hiding. Once you got it, it's insecure. 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.

wolf550e 10y ago

Too late to edit. I meant "does not reveal the key", of course.

rurban 10y ago

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

geofft 10y ago
> usually by poking into memory or by solving via order-exposure and timing attacks. 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.
zx2c4 10y ago
"Poking into kernel memory" is not possible without a serious security vulnerability. That's not within this threat model. "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?
tptacek 10y ago
Since it's trivial to "brute force" any cryptographic construction given its key, I remain confused as to the point you're trying to make here.
atoponce 10y ago
> The only SipHash security you get is seed hiding. Once you got it, it's insecure. 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.