Re: [openpgp] Fingerprints

[Phillip Hallam-Baker <[e-mail]>]

On Wed, May 6, 2015 at 2:38 PM, Christoph Anton Mitterer
<[e-mail]> wrote:
> On Tue, 2015-05-05 at 21:34 -0400, Phillip Hallam-Baker wrote:
>> I don't think so. Particularly if we are going to Base32 encoding and
>> make sure that there is no confusion between the legacy SHA-1
>> fingerprints and the new ones.
> Which is easily achieved when we add some algo/version qualifier as it
> was propsed before.

One of the reasons I suggested the code numbers for SHA-2 and SHA-3
that I did earlier is they guarantee that the first letter of the
fingerprint will be M (SHA-2 'Merkle') or S (SHA-3 'Spongeworthy').
Thus ensuring that they are distinct from SHA1 fingerprints.


>> Which is why I would like to move to a fingerprint format that can be
>> used with any protocol. Do it once, do it right and we don't have to
>> do it again.
> In principle I'd agree... apart from that I don't believe we'll never
> have to do it again (in the sense of exchanging the algo).

The leading byte gives both the method of constructing the hash and
the algorithm to use. I suggest we define code points for SHA-2 and
SHA-3 using an identical construction approach.



> However, as for the "core" standard I'd still only specify a simplest
> form of a fingerprint string format.
> e.g. something like
> <algo/version>:<FPdata>
> and then for the "current" algo/version e.g.
> 0:<base32 of the SHA3-512 FP>
> (i.e. the length would be dependant on <algo/version>.

I think we can go even simpler:

Fingerprint = Base32ify (BinaryFP)

BinaryFP = ID + H( HashedValue)
HashedValue =  <Content-Type> ':' <Data>

Since the MIME content registry does not permit entries with a colon
in the tag, this is guaranteed to be unambiguous. And since a
Content-Type can be defined for any data object that might need to be
hashed, it can support any content.

All the PGP related information would go in the <Data> field, so that
would include the PGP format version identifier, algorithm code, etc,
etc.


> Any further specifications, like how to map this into URLs or that like
> should probably go into a separate RFC.
> As should any further "formats" like a QR code representation of the FP.

All that would be needed in the PGP spec would be a definition of the
PGP Key Packet and a MIME registration (if not already registered).

We should definitely split the consideration of QR codes etc out of
the PGP doc. We probably want to define the QR code in such a way that
a device can recognize that a QR code is intended to be a PGP key and
handle it appropriately. We also want to make sure we don't waste bits
in QR space. And it has to be possible to convert an ascii fingerprint
to QR format.


>> We do not even need to decide on a strength. Just make is so that the
>> number of significant bits is however many bits that are provided. We
>> can all use SHA-2-512 or SHA-3-512 and truncate to 125, 150, 250...
>> bits as the application requires.
> I'm a bit sceptical about that... I think we rather should specify some
> lengths/format and at least not encourage implementations to choose what
> they think would be enough (cause then we have folks like GNOME which
> take the first and last byte or so *grin*)

If we are using Base32 and character groups of 5 characters (7-2
rule), the keys naturally come in 25 bit increments.

A 125 bit fingerprint has 117 bits and looks like this:
MFRTK-NJSMF-STOMR-WG5ST-ONZXGA

If we go for 150 bits we get:
MFRTK-NJSMF-STOMR-WG5ST-ONZXGA-YDKZB

>From a security point of view, we really don't need to go beyond 128
bits unless we are planning to use 256 bit encryption.

I think that either of those is acceptable on a business card.


The QR code equivalent is manageable even without format tweaks (attached).


In 'under the covers' applications the user does not need to see, I
would hope we would support use of the 256 bit or full 512 bit
fingerprint. I would also hope we can use the possibility of an online
store to 'stretch' a fingerprint. If the user types in a 25 character
fingerprint, the system can get the rest off a key service.