5

I just recently learned that the SHA-3 finalist Keccak allows for variable length output. As the only answer to this question states, "[it] need to have an output length at least equal to the input length," which I understand just fine. However, I'm curious if this guarantees against collisions.

  • Is there any work done to show or prove collision resistance gained by increasing digest length? If so, how dependent is this resistance on the hash function itself? (I'm guessing the answer to this is "highly" or "entirely".)
  • What are the other benefits of allowing variable and arbitrary length output?

If the math on these points is still fuzzy, is variable length output just based on the intuition that "larger problem space = harder to attack"?

Note my crypto and math expertise is very low, so please add a 'for dummies' section to any answer you write and I thank you in advance.

Community
  • 1
Patrick M
  • 429
  • 8
  • 15

2 Answers2

6

Is there any work done to show or prove collision resistance gained by increasing digest length?

Actually, as CodesInChaos has mentioned, the variable length versions of Keccak ("SHAKE128" and "SHAKE256") are known not to have any collision resistance beyond their security level, independent of how long we make the output.

So, what's the point? So, as you ask:

What are the other benefits of allowing variable and arbitrary length output?

That's because collision resistance isn't the only property we want from a random-looking function. One such alternative use is a Key Derivation Function; this is a function that takes as input some secret data (e.g. DH shared secrets) and some public data (e.g. nonces) and converts that into session keys; these are a series of encryption and MAC keys (and as we might have several such keys, and they're of variable length, this set of session keys is long and of variable length). Now, a number of KDFs are in use by real protocols (such as TLS), however these constructions are ad hoc, and actually rather ugly looking. It would be nice to use a single function that's designed to do that; a "variable length hash" (or XOF, that's what NIST dubs it) may be cleaner.

poncho
  • 154,064
  • 12
  • 239
  • 382
3

Are variable-length crypto hash functions still susceptible to collisions?

Yes. Even if you choose an output length equal to the input length, you expect some collisions from even an ideal PRF. E.g., if my test code works: $\operatorname{SHAKE256}(\text{'6'}, 8) = \operatorname{SHAKE256}(\text{'8'}, 8)$.

Is there any work done to show or prove collision resistance gained by increasing digest length?

Yes, up to the security bound. According to FIPS 202, the SHA-3 draft, the variable length SHAKE functions claim the following collision resistance:

SHAKE128: min(d/2, 128)

SHAKE256: min(d/2, 256)

where 'd' is the output length in bits.

The collision resistance depends on the output length, but for SHAKE256 can go higher than the collision resistance of the corresponding SHA3-256 function, which is limited to 128 bits due to its 256-bit output.

This is because the 512-bit capacity used in SHA3-256 is higher than required for 128-bit collision resistance, so that it can have the higher 256-bit preimage resistance matching other hash functions. This $c=2n$ was not always to be the case: at one point they planned for $c=n$ which would have given e.g only 128-bit preimage resistance for SHA3-256.

If so, how dependent is this resistance on the hash function itself?

The proofs for SHAKEs go back to the sponge construction that Keccak uses. It is not applicable in general to functions that use other constructions.

otus
  • 32,462
  • 5
  • 75
  • 167