21–30 of 52 posts
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.
His arguments on siphash are pretty practical, not sure what did you find misinformed there.
There's been nothing published to that effect, even though he has claimed for years that he can recover bits from the seed.
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.
For someone who isn't following the hashing function 'scene', what's misinformed about this rant?
I’d really like to see progress on hashes that fit into a few lines of code. It seems FNV-1a is still the best option in that regard.
This would delay rainbow tables
For security porpose, i thought -> slower performance = better. This would delay rainbow tables
They are not meant for cryptographically strong fingerprinting.
For security porpose, i thought -> slower performance = better. This would delay rainbow tables
>> Even if [...] worse hash functions will lead to more collisions, the overall speed advantage beats the slightly worse quality.
For security porpose, i thought -> slower performance = better. This would delay rainbow tables
For password hashing, you generally want a work function to increase the resource usage, or some alternative way of making cracking harder. That’s the case you’re thinking of, and it’s a very specific application, not what this new hash function is designed for.
> SipHash is not secure enough for security purposes and not fast enough for general usage. I beg your pardon? The author seems very confused.
To expand on this, SipHash is designed to mitigate a certain kind of DOS attack. It’s not a cryptographic hash. SipHash will still be a top choice for general purpose hashing with inputs that can be chosen by an adversary.