14

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”?

otus
  • 32,132
  • 5
  • 70
  • 165
GBleaney
  • 243
  • 2
  • 5

2 Answers2

14

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.

otus
  • 32,132
  • 5
  • 70
  • 165
  • Why say "fast"? It only blurs the (valid) argument IMHO. $;$ +1 for the remark that SipHash could still be a cryptographically strong MAC. – fgrieu Jul 04 '14 at 06:16
  • 5
    @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. – otus Jul 04 '14 at 06:29
  • Ah, yes, that's an excellent reason. – fgrieu Jul 04 '14 at 06:32
  • ‘[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. – Squeamish Ossifrage Nov 15 '19 at 01:23
  • @SqueamishOssifrage, not irrelevant in the context of the question IMO. – otus Nov 16 '19 at 22:28
  • 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. – Squeamish Ossifrage Nov 17 '19 at 04:37
  • @SqueamishOssifrage, it is relevant because the algorithm is named (IMO misnamed) SipHash, even though it is not a cryptographic hash. – otus Nov 17 '19 at 07:40
  • 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. – Squeamish Ossifrage Nov 17 '19 at 15:19
  • We'll have to agree to disagree. There is a specific meaning for croptographic hash. Collision resistance is implied. – otus Nov 17 '19 at 19:19
7

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

Community
  • 1
archie
  • 1,988
  • 17
  • 28