I'm evaluating different hash algorithms for use in my application. One of the kind of algorithms I am looking at are cryptographically secure ones to protect against DOS attacks.

SipHash seems pretty great, but the creators seem very careful to not call it "cryptographically secure".

In the SipHash paper (PDF), they call it “cryptographically strong”, but not secure. Is there any reason to trust SipHash over SpookyHash if both have no known DOS attacks and neither is “cryptographically secure”?


2 Answers 2


A fast 64-bit hash cannot be completely secure, since a $2^{32}$ brute force collision search is completely doable, and even a $2^{64}$ preimage attack could be feasible.

As a MAC used for hash table keying, that doesn't really matter (unless you leak the key). Finding just a few collisions isn't a problem and gathering statistics for an attack would probably already constitute a DOS attack.

That is to say, SipHash isn't a secure hash function, but should be a strong PRF and thus a secure MAC.

  • $\begingroup$ Why say "fast"? It only blurs the (valid) argument IMHO. $\;$ +1 for the remark that SipHash could still be a cryptographically strong MAC. $\endgroup$
    – fgrieu
    Jul 4, 2014 at 6:16
  • 5
    $\begingroup$ @fgrieu, because whether $2^n$ operations is feasible in the real world depends on how long an operation takes. You could define a 64-bit hash function using $2^{96}$ iterations of SHA-256 (e.g. in PBKDF2) and a collision search would take the same time as that for SHA-256 (~$2^{128}$ SHA-256 operations). Since such a hash would be completely unusable, I suppose my hedging was unnecessary. $\endgroup$
    – otus
    Jul 4, 2014 at 6:29
  • 1
    $\begingroup$ ‘[B]rute force collision search’ and ‘preimage attack’ are irrelevant, because SipHash is a (keyed) PRF, not a fixed hash function. The first paragraph of this answer seems to be addressing security properties that SipHash doesn't even claim. $\endgroup$ Nov 15, 2019 at 1:23
  • 1
    $\begingroup$ It is no more relevant than SipHash's security as a public-key key agreement scheme or as a brick wall. It's confusing and counterproductive to start by saying it ‘cannot be completely secure’ when you're referring to a security property that was never advertised in the first place. $\endgroup$ Nov 17, 2019 at 4:37
  • 1
    $\begingroup$ It's not a collision-resistant hash, but there are many kinds of ‘hash’ in cryptography most of which are not collision-resistant. If you want to clarify the situation, specify the security goal; don't just say ‘cannot be completely secure’ at a security goal that was never advertised in the first place. Here the name ‘hash’ is presumably in contrast to things like cityhash and murmurhash—which are also keyed and used for hash tables but provide no cryptographic security. $\endgroup$ Nov 17, 2019 at 15:19

This may just be a matter of terminology.

A claim that an algorithm is "secure" is meaningless without qualifying/quantifying what it is secure against. Conventionally, the security/strength of cryptographic primitives is described and analysed in terms of computational and memory cost (i.e. secure against an attacker capable of performing a certain number of computations and using a certain amount of memory).

The SipHash authors argue that SipHash is a strong PRF, and make claims/arguments for the level of strength, and later in the SipHash specification the authors equate strength to "level of security".

SipHash-c-d with c ≥ 2 and d ≥ 4 is expected to provide the maximum PRF security possible (and therefore also the maximum MAC security possible). Our fast proposal is thus SipHash-2-4. SipHash-2-4.

We define SipHash-c-d for larger c and d to provide a higher security margin: our conservative proposal is SipHash-4-8, which is about half the speed of SipHash-2-4


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.