Key fingerprints (not the DNS kind)

[Ángel González]

On 08/11/14 17:36, Christian Weisgerber wrote:
> 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?
Is it so important to compact it?
Yes, 
c4:e8:62:87:71:72:93:2c:c3:93:a8:ae:c5:c0:c2:bf:2f:8a:2c:1c:fa:8c:91:28:c9:1d:aa:0c:f6:0c:f0:fb 
is
quite longer than 87:67:c9:7b:6e:d9:b6:a3:3b:dd:02:0e:de:51:15:8d but 
the people who check fingerprints
will still check a longer one, and the people who doesn't won't care.

> Base64?  Truncate (eww, can o' worms)?
No. If you truncate a N-length hash to M < N, you could (will probably) 
end up with a weaker hash than the md5
you were trying to replace. The hash resistence is for the full-length hash.

If you wanted to provide a short fingerprint, I would simply replace 
MD5(key) with MD5(SHA256(key)).* The unpredictability
of the inner hash protects against the ability of manipulating the key 
for creating collisions.

* Plus something that makes old and new fingerprints look different.


> And how to manage the changeover from old to new fingerprints?
Provide a ssh argument (a comma-separated list of ways) for choosing 
which fingerprints to show. If the user was
provided a fingerprint of type A, but has a newer ssh defaulting to type 
B fingerprint, it can use that switch to request
that it is shown with the format he was given.
Note this is quite similar to hosts with ECDSA and RSA keys.

An additional possibility is to change the "Are you sure you want to 
continue connecting (yes/no)?" prompt to also accept
the right fingerprint. If there are several fingerprints, ssh could 
verify that it matches the provided pubkey, automatically switching
to the right algorithm for such fingerprint.