Key fingerprints (not the DNS kind)

[Damien Miller]

On Sat, 8 Nov 2014, Christian Weisgerber wrote:

> When you connect to a server for the first time, a fingerprint of
> the server's public key is presented.  The idea is that if you
> already know the fingerprint and it's a match, you can be confident
> that you are talking to the server and not a man-in-the-middle.
> 
> People use this, e.g.:
> http://www.openbsd.org/anoncvs.html
> 
> The typical fingerprint is just an MD5 hash over the public key.
> Given how broken MD5 is, you have to wonder if a MitM can create a
> new key with the same fingerprint.  I'm in particular concerned
> about RSA keys, which are long and provide material to work with.
> In fact, isn't this Lenstra/Wang/Weger's "Colliding X.509 Certificates"
> attack from 2005?
> 
> Am I missing something?

It isn't exactly the same attack - certificates have lots of places where
the attacker can stash data to set up the hash collision that plain keys
lack, but we do really need to switch away from MD5.

> Bubble Babble fingerprints are only displayed by ssh-keygen -B,
> which is of limited usefulness.  It looks like the sort of arcane
> feature that could just be removed.

No, these are for interop with other SSH implementations.

> The other fingerprint formats should switch from MD5 to SHA-256 as
> the underlying hash.  The devil is in the details.  How to display
> a SHA-256 hash compactly?  Base64?  Truncate (eww, can o' worms)?
> And how to manage the changeover from old to new fingerprints?

I'm not so concerned about how to display the new fingerprints. Say
we choose SHA512/224, which yields a 28 byte hash. Rendering this as
base64 gives us a 38 character string, well shorter than our current
key fingerprints. (e.g. "GIeKHpiBrP7zaEf7Blicgvez5JceCBfSaESlkA")

The randomart signatures are a bit more tricky to deal with - there
isn't any room to put a hash algorithm identifier in the header line
("ED255519  256" doesn't leave enough characters). Maybe it could go
in the footer...

The bigger problem is transition. We would need to be able to show both
old and new fingerprints for a while, but there is no consistent way to
do this for all the tools. ssh and sshd could use a config option easily
enough, but the other tools don't generally read the config files and
there are AFAIK no getopt chars left that can be consistently used
between all the tools.

I guess we're going to be stuck with an config knob for ssh/sshd and
an flag for ssh-add/ssh-keygen (but no flag for ssh/sshd).

-d