Think of an abstract hash function as a black-box mapping from an arbitrary input to a finite output.
Since the number of possible inputs is infinite, if you assume the function to approximate a stable (because it's a hash), random (cryptographic) mapping of input to output, each output value must have an infinite number of collisions (
infinite input space / finite output space)
They're just randomly distributed, an average of
2 ^ $output_bits (far) apart. Note that for this to be true, the size of the input doesn't matter; just the fact that it is a function which takes any input and produces a bounded output.
A perfect* hash function might have 1:1 mapping for inputs of exactly the output length; with any practical hash function once the number of input values becomes significant, the "birthday problem" should be noted, in that while the chance of any pair of items colliding is small, as the number of items grows the number of pairs which might collide grows with
n! so the probability of any collision rapidly approaches 1. In your example, 16 bytes is a lot of
If the input is shorter than the output, where does the extra output space come from? Since we have only one input, the answer must be derived from the input or internal to the function (constant).
Practically, hash implementations mix similar short inputs with padding and the input length itself to distinguish
0000 0101 as part of the standard interface specified to the particular cryptographic primitives.
*yes; for this purpose, the identity
f(x) = x is a "perfect" hash function (no collisions), but has some confidentiality flaws.