| ▲ | Tuna-Fish 7 hours ago | ||||||||||||||||||||||
But if you know the hash table implementation, it makes forcing collisions trivial for user-generated input, leading to easy denial of service attacks. The first requirement for safe hashtable implementations is a secret key, which makes it impossible to know the hash value for an external observer. (Or even, to know the relative hash value between any two inputs.) | |||||||||||||||||||||||
| ▲ | josefx 5 hours ago | parent | next [-] | ||||||||||||||||||||||
> The first requirement for safe hashtable implementations is a secret key, Some languages use different approaches. The buckets in a Java HashMap turn into a sorted tree if they grow too large. Then there are trivial solutions like adding an input limit for untrusted users. Either way works, is secure and doesn't depend on a secret key. | |||||||||||||||||||||||
| ▲ | xnorswap 7 hours ago | parent | prev [-] | ||||||||||||||||||||||
Did you reply to the wrong comment, I'm not sure it follows from what I posted? You can't force a collision for the function f(x) = x, by definition it has no collisions. It's not just collision-resistant, it's actually collision proof! hash(x) = x is of course not a cryptographic hash, but it also has the advantage that it's unlikely to be confused for one if anyone looks at the output. | |||||||||||||||||||||||
| |||||||||||||||||||||||