5 ms·

The small key performance is very nice. It would be good to have more written about this new hash function, and less misinformed rant about siphash.

rurban 8y ago
> misinformed rant Only siphash fans would say that, and they are very misinformed about the false recommendations from their paper. Prove me wrong.
- Twirrim 8y ago
  No, that onus is on you. If you've got specific critique of siphash I'm sure people would like to read them. As it is, you're making somewhat vague denunciations without providing any substance to back them up.
- jessaustin 8y ago
  You're the one posting your own page to HN, so I think maybe you have the burden of proof here?
- jchw 8y ago
  I didn't know much about this argument so I looked it up and funny enough it's you arguing here too: https://github.com/google/highwayhash/issues/28 https://github.com/google/highwayhash/issues/28 Still trying to wrap my head around exactly what is being argued... but it's starting to feel like there's something personal going on here, not gonna lie. It's a bit quaint. (Also a bit curious why Rust is looped into this. It seems like Rust was insecure because the same key was being used for all tables, not really because the hash function was insecure?)
  - CodesInChaos 8y ago
    I think the claim isn't "SipHash is not a secure keyed hash function (PRF)" but rather "secure keyed hash functions are insufficient mitigation for hash DoS". For long lived hash-tables even per-table keys don't prevent finding bucket-collisions via side-channels. So you either have to either rekey when a large number of bucket-collisions are detected. Or you fall back to a balanced tree based data structure for those buckets. If you prefer the latter mitigation, there is little reason to pay the performance hit of SipHash. So the OP has a point, but is terrible at communicating it.
    - jchw 8y ago
      Well, I am not a cryptographer, so I can't really make much attestations myself, but here's what I read: - OP claims that the security claims of SipHash are incorrect or misleading. - SipHash paper author defends claims made in SipHash paper. - OP responds, claims that the security properties are misleading because most people would just assume it meant it was a "secure hash" and not a secure PRF. To prove this, he alludes to a Rust bug that as far as I can tell would work exactly the same with any hash function. So I'm curious. Can you recover the seed in SipHash with side channel attacks? The response can be summed up as "PoC||GTFO," and I tend to agree; it seems to contradict at least some of the security claims they are making, after all. All in all, if they have a point, it's missed in the flurry of unrelated points that were brought up there, and I definitely am not sure what to take away from it.
    - GoblinSlayer 8y ago
      He means the worst case scenario when the attacker knows the key. In which case it's trivial indeed.
      - rurban 8y ago
        As I explained there, getting the hash seed of a running process in a dynamic language is trivial. Every language has enough ropes to hang yourself and print the value from some known offset. And if not, there's still enough information from a typical bad hash table (95% of hash tables are bad) to get at the seed via ordering and timing. From there you just brute force an attack even with an extremely slow hash like siphash. A seed is no secure protection against an determined attacker, only for newbies. A newbie would just DOS the system with simplier means. The point is, don't believe the theatre, use proper protection against the attack (no linear list on collisions), and keep the hash table fast. Collision counting or fallback to tree really is trivial.
        minitech 8y ago
        > And if not, there's still enough information from a typical bad hash table (95% of hash tables are bad) to get at the seed via ordering and timing. Really? How’s that? The SipHash seed isn’t supposed to be recoverable from hashes – that would be a pretty significant break – and I don’t see what other route the hash table would have to the seed. > Every language has enough ropes to hang yourself and print the value from some known offset. You mean explicitly reading the seed out for an attacker? If we’re modifying the program to help, I figure while (true) {} is probably a simpler DoS.
- gliptic 8y ago
  Have you published your SipHash seed finder yet?
  - rurban 8y ago
    A seed finder is independent on the hash function. It is dependent on the framework you are using. If you are using perl, ruby, python or php e.g. I won't publish the perl solution as nobody is protected and I had my own services on Redhat Openshift, which is unsafe forever. I only published the proof of the various attacks on most hash functions in my testsuite, to verify the proper protection against it.
zingmars 8y ago
For someone who isn't following the hashing function 'scene', what's misinformed about this rant?
- WallWextra 8y ago
  Most of his arguments simply do not apply to the relevant use case and attacks. The only one that does, the claim that the seed is recoverable, is not an argument at all but a vague, unsubstantiated claim.
zzzcpan 8y ago
His arguments on siphash are pretty practical, not sure what did you find misinformed there.
- gliptic 8y ago
  From the readme: "SipHash is not secure enough for security purposes" There's been nothing published to that effect, even though he has claimed for years that he can recover bits from the seed.

rurban 8y ago

> misinformed rant Only siphash fans would say that, and they are very misinformed about the false recommendations from their paper. Prove me wrong.

Twirrim 8y ago
No, that onus is on you. If you've got specific critique of siphash I'm sure people would like to read them. As it is, you're making somewhat vague denunciations without providing any substance to back them up.
jessaustin 8y ago
You're the one posting your own page to HN, so I think maybe you have the burden of proof here?
jchw 8y ago
I didn't know much about this argument so I looked it up and funny enough it's you arguing here too: https://github.com/google/highwayhash/issues/28 https://github.com/google/highwayhash/issues/28 Still trying to wrap my head around exactly what is being argued... but it's starting to feel like there's something personal going on here, not gonna lie. It's a bit quaint. (Also a bit curious why Rust is looped into this. It seems like Rust was insecure because the same key was being used for all tables, not really because the hash function was insecure?)
- CodesInChaos 8y ago
  I think the claim isn't "SipHash is not a secure keyed hash function (PRF)" but rather "secure keyed hash functions are insufficient mitigation for hash DoS". For long lived hash-tables even per-table keys don't prevent finding bucket-collisions via side-channels. So you either have to either rekey when a large number of bucket-collisions are detected. Or you fall back to a balanced tree based data structure for those buckets. If you prefer the latter mitigation, there is little reason to pay the performance hit of SipHash. So the OP has a point, but is terrible at communicating it.
  - jchw 8y ago
    Well, I am not a cryptographer, so I can't really make much attestations myself, but here's what I read: - OP claims that the security claims of SipHash are incorrect or misleading. - SipHash paper author defends claims made in SipHash paper. - OP responds, claims that the security properties are misleading because most people would just assume it meant it was a "secure hash" and not a secure PRF. To prove this, he alludes to a Rust bug that as far as I can tell would work exactly the same with any hash function. So I'm curious. Can you recover the seed in SipHash with side channel attacks? The response can be summed up as "PoC||GTFO," and I tend to agree; it seems to contradict at least some of the security claims they are making, after all. All in all, if they have a point, it's missed in the flurry of unrelated points that were brought up there, and I definitely am not sure what to take away from it.
  - GoblinSlayer 8y ago
    He means the worst case scenario when the attacker knows the key. In which case it's trivial indeed.
    - rurban 8y ago
      As I explained there, getting the hash seed of a running process in a dynamic language is trivial. Every language has enough ropes to hang yourself and print the value from some known offset. And if not, there's still enough information from a typical bad hash table (95% of hash tables are bad) to get at the seed via ordering and timing. From there you just brute force an attack even with an extremely slow hash like siphash. A seed is no secure protection against an determined attacker, only for newbies. A newbie would just DOS the system with simplier means. The point is, don't believe the theatre, use proper protection against the attack (no linear list on collisions), and keep the hash table fast. Collision counting or fallback to tree really is trivial.
      - minitech 8y ago
        > And if not, there's still enough information from a typical bad hash table (95% of hash tables are bad) to get at the seed via ordering and timing. Really? How’s that? The SipHash seed isn’t supposed to be recoverable from hashes – that would be a pretty significant break – and I don’t see what other route the hash table would have to the seed. > Every language has enough ropes to hang yourself and print the value from some known offset. You mean explicitly reading the seed out for an attacker? If we’re modifying the program to help, I figure while (true) {} is probably a simpler DoS.
gliptic 8y ago
Have you published your SipHash seed finder yet?
- rurban 8y ago
  A seed finder is independent on the hash function. It is dependent on the framework you are using. If you are using perl, ruby, python or php e.g. I won't publish the perl solution as nobody is protected and I had my own services on Redhat Openshift, which is unsafe forever. I only published the proof of the various attacks on most hash functions in my testsuite, to verify the proper protection against it.

zingmars 8y ago

For someone who isn't following the hashing function 'scene', what's misinformed about this rant?

WallWextra 8y ago
Most of his arguments simply do not apply to the relevant use case and attacks. The only one that does, the claim that the seed is recoverable, is not an argument at all but a vague, unsubstantiated claim.

zzzcpan 8y ago

His arguments on siphash are pretty practical, not sure what did you find misinformed there.

gliptic 8y ago
From the readme: "SipHash is not secure enough for security purposes" There's been nothing published to that effect, even though he has claimed for years that he can recover bits from the seed.