Re: [openpgp] Fingerprints

[Christoph Anton Mitterer <[e-mail]>]

On Wed, 2015-05-06 at 16:38 -0400, Phillip Hallam-Baker wrote: 
> 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.


> 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.
In principle I'd like to see that both algos can generally be used with
a future OpenPGP, given the different class (Merkle-Damgard vs Sponge),
generally for the FP and other areas.

But I guess the majority here would want to have only one algorithm, at
least for the FP.
Is there any broad consensus already about SHA2 vs. SHA3 (except the
traditionalist argument)?



> I think we can go even simpler:
> 
> Fingerprint = Base32ify (BinaryFP)
> 
> BinaryFP = ID + H( HashedValue)
> HashedValue =  <Content-Type> ':' <Data>
Isn't that what I've said? Or what is ID in your text?

At least I think the user should directly see the algorithm/version
without needing to decode the baseXXX.


> 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.
Nah... that's bad IMHO... I really would want to know which algo I use
without turning on some BASExx decoder (which doesn't mean that one
cannot include it there as well).

And what's the content-type then in your thinking, if it's not the algo?
Just the information "this is a OpenPGP fingerprint"?
Then as I've said previously,.. I think this doesn't need to be part of
the core standard of OpenPGP,... but if it would be really just a
handful of MIME types e.g. one for "OpenPGP fingerprint" I would neither
strongly oppose this.


> 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.
I should perhaps notice again, that in general it's IMHO rather a bad
idea to standardise "fingerprint formats" which are not directly
readable (including QR code or things like OpenSSH's ASCII art version
of the FP).



> 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.
(The later, ) which would be nice... 

We already have curves for that...


Cheers,
Chris.