Even though MD5 has been broken for years and its vulnerabilities have been used to create real-world rogue X.509 CAs and other horrible things, OpenSSH and PuTTY still use MD5 as the default public key fingerprint algorithm.

Is there a way to switch to something more secure for this purpose? Even SHA-1 would be somewhat better, although I would not prefer it.

Notice that for the validation of public keys via SSHFP DNS records, SHA-1 is already in use (and in a proposed extension also SHA-256)

  • 1
    Doesn't sound that bad to me. While using stronger hashes is certainly nice, I can't think of a practical attack on MD5 fingerprints. – CodesInChaos Nov 10 '12 at 10:33
  • Maybe I have a misconception about this, but how is using MD5 as a fingerprint for manual user matching less attackable by collision attacks than the following: phreedom.org/research/rogue-ca ? – aef Nov 10 '12 at 10:47
  • 2
    Okay, that rogue CA attack, they created 2 certs together that had the same MD5 hash, then sent one to be signed as a CA cert. They then copied the signature to the other one to actually sign some stuff. What they did not do is take a cert for a keypair already in existence and find a matching set of data. In SSH if one can engineer the server to use a key that is compromised in a similar way, well, one has bigger problems as the server is well and truly compromised. – ewanm89 Nov 10 '12 at 12:25
  • What you need to do what you are suggesting without generating both messages together is a first order preimage attack, which does not yet exist for MD5 (not efficient enough to be usable anyway). Yes we should probably start using SHA-1 or SHA-2 for key fingerprinting in SSH but it's not actually an issue yet. – ewanm89 Nov 10 '12 at 12:27
  • 2
    @aef The difference is who creates the key. In the CA model that's a potential attacker. In the fingerprint model he's benign by definition. – CodesInChaos Nov 10 '12 at 13:33

Collisions are not an issue for key fingerprinting. Key fingerprinting relies on resistance to second preimages. To say things simply:

  • In a collision attack, the attacker tries to build two distinct messages m and m', which hash to the same value.

  • In a second preimage attack, the attacker tries to build a message m', distinct from a fixed, imposed message m, such that both messages hash to the same value.

The difference is quite crucial. While MD5 is thoroughly broken with respect to collisions, it is not for second preimages. As such, there is no urgency to replace it. New protocols should rely on better hash functions (like SHA-256), but there is no use in breaking existing protocol by evicting a still serviceable MD5.

Your Answer

