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.
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
