Re: Key fingerprints?

How can we have this whole conversation without mentioning Bubble Babble?

http://wiki.yak.net/589/Bubble_Babble_Encoding.txt

This was originally designed by SSH, and has been implemented in Bitvise 
products since our first versions.

All our products show Bubble-Babble fingerprints. For example:

xubem-kiloc-getad-ponyh-sagyb-sunyp-zirog-ninif-ponak-pisob-luxex

This is Bubble-Babble for a 1024-bit DSA key.

denis


-----Original Message----- 
From: Mouse
Sent: Saturday, December 01, 2012 16:44
To: [email protected]
Subject: Key fingerprints?

I've got a couple of suggestions for ssh implementors.

SSH implementations - or at least a few of them - use key fingerprints
to summarize keys to users, such as in "no host key saved for this
host, here's the host key we got, accept it?" questions.

As far as I can tell, how this is done is not standardized.  4251
appears to consider it an implementation choice, with a mild suggestion
of SHA-1 hashes converted to hex.  It seems to me it is in everyone's
interest for fingerprints to be comparable between implementations,
which calls for some kind of standardization, even if only de facto.

When I was writing moussh I investigated this a ltitle bit and it
appeared to me that the only other implementation I had at ready hand
(some version of OpenSSH, probably) used MD5 hashes of the public-key
data blobs, converted to hex with : used as an octet separator, a la
01:23:45:67:....  Since I wanted hashes fingerprints to be compatible,
that's what I implemented.

Since then, I've added a more compact - and, I find, easier to compare
by eye - representation, the same data content as the hex style but
represented in base 85 using most of the printable ASCII characters;
moussh now prints both forms in most cases when it has occasion to
print key fingerprints.  I've also seen a two-dimensional "random art"
representation, but I know nothing about the details behind it.

On another note, MD5 is showing weaknesses.  So far, all I've actually
seen reported is collision failures, but I expect second-preimage
failures to show up before too much longer.  While there isn't a whole
lot of wiggle room in key data blobs to take advantage of second
preimages, there is some.  So, I'd like to use something stronger than
MD5, but I also don't want to disturb people by presenting fingeprints
that appear to disagree with other implementations' fingerprints for
the same keys.  This means at least some degree of coordination with
how other implementations compute and present fingerprints.

So, here's what I'd like to do.  To be useful, these need different
implementors to work together, which is why I'm writing here: to
suggest that we collaborate on these.

- I'd like to collect specifications for the various fingerprint
   formats in use, with an eye to publishing them in some form,
   preferably with test vectors.  I can do the collecting and
   collating, and, in a minimal form, the publishing (a text file up
   for FTP or HTTP fetch); if these are considered valuable enough,
   someone else might want to publish them in other way (such as,
   perhaps, an Informational RFC).

- I'd like to come to some kind of agreement for how to compute and
   represent fingerprints in a way that's a bit more future-friendly
   with respect to hash algorithms than just printing hashes in hex.

/~\ The ASCII   Mouse
\ / Ribbon Campaign
X  Against HTML [email protected]
/ \ Email!      7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B