Subject: [Curdle] Server Fingerprints using UDF

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 24 Aug 2016 14:07:05 -0400

One of the things I am trying to persuade groups writing crypto
applications is that we should adopt a common format for fingerprints, Why?

1) Because having a standard approach is the right thing to do

2) Because a direct trust mechanism (i.e. a fingerprint) is useful in every
crypto application

  * OpenPGP Key fingerprints
  * SSH server keys AND it would be nice to do public keys one day
  * Roots of trust for PKIX and S/MIME

3) Because simply taking SHA-2 of 'stuff' opens possibilities for semantic
substitution attacks

4) Adopting a common format encourages innovation that can benefit all
applications that share that format.

5) Adopting a single fingerprint format encourages the development of
applications to manage them across applications - like the Mathematical
Mesh which I am working on.

We are not going to get to one true representation of keys. But I think we
could get to a fingerprint format that every application can use without
the risk of semantic substitution attacks.

I am not too bothered about the possibility that someone generates an
OpenPGP key and somehow persuades S/MIME to send a message using the same
key. If I am being really strict, I can see it is not ideal.

What does worry me however is that if Mallet gives Alice his key
fingerprint for OpenPGP, she puts it in her 'trusted key ring' and it turns
out that when the SSH app interprets the sequence of bits that were
fingerprinted they have some different semantics.

My current proposal is in:

https://tools.ietf.org/html/draft-hallambaker-udf-03

This allows use SHA-2-512 and SHA-3-512 as the hash algorithms. The default
presentation is as a text string encoded in BASE32 encoding with spacing
every 5 characters to promote readability.

So a SSH server fingerprint might look like:  MB2GK-6DUF5-YGYYL-JNY5E-RWSHZ

One of the things I find rather difficult with SSH is that the key files
for the applications I have seen in the wild do not comply with the spec,
lines don't wrap at 72 characters. Rather worse, the files have the full
public key in them which makes them a real pain to use when configuring
files.

I would really like to be able to configure my GitHub accounts without
having to cut and paste lines with a thousand characters of text. It would
be nice if the SSH config files could use fingerprints rather than the
actual keys.

---

From: Peter Gutmann <[email-masked]>
Date: Thu, 25 Aug 2016 03:33:09 +0000

Phillip Hallam-Baker <[email-masked]> writes:

>2) Because a direct trust mechanism (i.e. a fingerprint) is useful in every crypto application
>

ObXKCD: https://xkcd.com/927/

>This allows use SHA-2-512 and SHA-3-512 as the hash algorithms.

Oh not another SHA-as-big-as-we-can-get.  We know from various (public-IP) 
Internet scans that the universal standard on the net is SHA-256, and 
anything else, in particular the huge SHA-2 variants, are the GPS signal
of the Internet, their use is so far below the noise floor that you need
specialised signal processing just to see they're there.  Just stick with
SHA-256, which pretty much everything does, rather than going to oddball
exotic algorithms that need special-case support.

Peter.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 25 Aug 2016 16:01:46 -0400

> exotic algorithms that need special-case support.

​It is for compatibility with this:
https://tools.ietf.org/html/draft-irtf-cfrg-eddsa-07

My approach is that I do not believe in giving the user unnecessary
options. In particular won't give a lower security option unless there is a
compelling performance reason. ​

So I use SHA-2-512 and truncate to however many bits as are needed.

Since people want to use OpenPGP with ed448 curves for a 2^256 work factor,
there needs to be a fingerprint option with equivalent strength.

The code is going to need SHA-2-512 anyway. Just standardize on the higher
level.