-
Notifications
You must be signed in to change notification settings - Fork 757
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We鈥檒l occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add SipHash to benchmarks...? #162
Comments
Sure, it's a good suggestion.
I need to find time to build a new benchmark platform for this though. |
Actually, I found some initial tests at this SMHasher fork, showing xxHash is at least twice as fast for small inputs and far faster for longer inputs. However, I think this won't be enough...
I think this is bigger a requirement than I realized, especially due to the risks related to flood-hashing attacks (for anyone else reading this, here is a high-level explanation and a more detailed one). I found this thread indicating that it's possible to produce collisions on demand. I don't know if it's possible to use this weakness to create multi-collisions and lead to hash flooding attacks... but I think a resistance to collision generation should be considered a requirement for widespread adoption. ... As a security related side note, by setting the first 32 bytes of a message to a specific value, all vectors are equal to the seed after the first round. This might be exploited to extract seed data or compromise the hash. I'm playing around with my own variation where I use irreversible manipulations to prevent this. |
As I'm going to make a new round of benchmark for the next |
FYI: I was inspired by XXHash's approach and used something similar in my own project / library (I named it RiskyHash - you can find the source code here). BTW: The more I read the less I'm impressed with the need for Hash function "security" where Hash Maps are concerned. IMHO, the Hash Map implementation should handle security concerns, not the Hashing function. Following this logic, using a faster Hashing function could add a significant performance boost. |
Yes, IMO, SipHash is overkill. Even with the "fast" 1-3 variant, its performance is less than half of XXH32. You only need a decent hash:
|
Added siphash to |
I just discovered this repo, and I love it 馃憤
I'm very impressed by both the function and the performance.
I'm curious if SipHash could be added to the benchmark suites? It has it's own Wikipedia page and appears to be implemented in many platforms and used by some Standard Libraries.
I know the benchmarks are half implementation and half algorithm design, but both Hash implementations appear mature enough to make curious if pushing Ruby and Python to adopt xxHash over SipHash might be a good idea.
Thanks!
The text was updated successfully, but these errors were encountered: