Are variable-length crypto hash functions still susceptible to collisions? 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.
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.