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?
There are three types of fingerprints that are shown to the user:
(1) MD5 in hex:
2048 58:32:84:2f:e6:06:be:99:7e:1f:4e:49:c9:ac:04:e5 id_rsa.pub (RSA)
(2) MD5 as random art:
+---[RSA 2048]----+
| ... |
| o.. |
| . E.o . |
| ..oo.* |
| . +..* S |
| ..oo . |
| =. + |
| + .o . |
| ... .o |
+-----------------+
(3) SHA-1 as Bubble Babble:
2048 xufok-vegum-ralym-tudob-zybyp-donyf-nifor-bocuc-behah-vilis-vexyx
id_rsa.pub (RSA)
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.
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?
--
Christian "naddy" Weisgerber naddy at
mips.inka.de
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.
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