Skip to content
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’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Switch hash function to SipHash. #718

Open
wants to merge 2 commits into
base: unstable
from
Open

Conversation

@PeterScott
Copy link

@PeterScott PeterScott commented Oct 22, 2012

SipHash is a cryptographically strong MAC designed for use in hash tables. Previously
Redis switched to murmur2 to try to prevent hash flooding DoS attacks:

da920e7

Unfortunately, murmur2 and murmur3 are both easy to attack, as there are algorithms which
can quickly generate arbitrarily many keys that all hash to the same value regardless of
what the seed is:

https://www.131002.net/siphash/murmur2collisions-20120821.tar.gz

By switching to SipHash, we get strong resistance to this kind of attack, without any
noticeable slowdown on either redis-benchmark or "DEBUG POPULATE 1000000". According to
the SUPERCOP benchmarks, this good hash performance holds true for both large and small
keys across all CPU architectures and models tested:

http://bench.cr.yp.to/impl-auth/siphash24.html

This patch also switches to using /dev/urandom as a source of high-quality randomness for
key generation on server startup, unless it is unavailable, in which case time and pid
are used instead.

PeterScott added 2 commits Oct 22, 2012
SipHash is a cryptographically strong MAC designed for use in hash tables. Previously
Redis switched to murmur2 to try to prevent hash flooding DoS attacks:

da920e7

Unfortunately, murmur2 and murmur3 are both easy to attack, as there are algorithms which
can quickly generate arbitrarily many keys that all hash to the same value regardless of
what the seed is:

https://www.131002.net/siphash/murmur2collisions-20120821.tar.gz

By switching to SipHash, we get strong resistance to this kind of attack, without any
noticeable slowdown on either redis-benchmark or "DEBUG POPULATE 1000000". According to
the SUPERCOP benchmarks, this good hash performance holds true for both large and small
keys across all CPU architectures and models tested:

http://bench.cr.yp.to/impl-auth/siphash24.html

This patch also switches to using /dev/urandom as a source of high-quality randomness for
key generation on server startup, unless it is unavailable, in which case time and pid
are used instead.
… randomization in case-insensitive hash function, since it's never used on user-supplied keys, and the 5381 constant empirically gives good results.
@PeterScott
Copy link
Author

@PeterScott PeterScott commented Oct 23, 2012

The second commit was needed to make GCC 4.5 happy; previously I'd only tested with Clang/MacOS, but now I've also tested with GCC/Linux. All tests pass, and as before, the performance difference is negligible. (On my tests, the new code usually looks slightly faster, but the difference is in the noise.)

@antirez
Copy link
Contributor

@antirez antirez commented Nov 11, 2012

Thanks, this feature is approved, I'll merge in the next days after review and speed regression testing.

@antirez antirez removed this from the Redis 2.8 milestone May 15, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

2 participants