On 11/11/2016 12:17 PM, Andrew Lutomirski wrote:
/me dons crypto hat.
SHA(x || k) has three problems, one of which is bad enough to be an absolute
showstopper.
1. Specify *which* SHA. SHA-1 should not be used for new applications.
2. Concatenation without some additional property preventing collisions of the
hashed data is problematic. In particular, if you shorten x by a byte and
prepend the same byte to k, you get the same output. This is probably
irrelevant for this particular use case, but it's still a sign that the
construction is bad.
3. The SHA hashes, like all Merkle-Damgård hashes, is subject to
length-extension attacks. In particular, if x is a multiple (or slightly above
a multiple) of the block length, then anyone who learns SHA(x) can efficiently
derive SHA(x || k). This basically removes all security from this scheme.
HMAC(k, x) would be much better.
But I think this protocol is generally more fragile then needed. How about
generating a per-app-installation random value and HMAC-ing *that* with the
machine id?
I think this is extreme overkill for something that doesn't need to be
cryptographically sound. It literally just needs to be eight characters with a
sensible random distribution. I considered using some non-reversible
transformation of machine-id for this simply because I wanted to avoid trying to
consume any of the entropy in /dev/random since we'd be doing this early in the
installer (when entropy tends to be at a premium). Maybe that was overkill and I
should just pull from /dev/random.
I can't think of a reason why we'd need a cryptographically secure
transformation just to generate a random hostname.