On Wed, May 6, 2015 at 5:31 PM, Christoph Anton Mitterer
<calestyo(_at_)scientia(_dot_)net> wrote:
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)?
The folk I have spoken to were of the opinion that the SHA3 contest
actually confirmed people's confidence in SHA2. So I don't see a need
to jump to the next bright shiny object.
SHA3 is supported in pretty much every stack now, SHA3 is still a bit
of a work in progress.
So I would suggest that SHA-2-512 be REQUIRED and SHA-3-512 be RECOMMENDED.
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.
Yes, and this should hold for both the base32 version and when doing a
hex dump of a binary fingerprint. So the ID should be a byte and the
top 5 bits should result in a letter in the range G-Z.
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).
The hash algorithm id is in the <BinaryFP>. The <data> field needs to
have the algorithm of the public key.
And what's the content-type then in your thinking, if it's not the algo?
Just the information "this is a OpenPGP fingerprint"?
yes.
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.
I think the OpenPGP system would end up using at least two codes, one
would be 'OpenPGP fingerprint' and the other would be for 'Something
like TRANS that does not have ASN.1'.
Fixing key signatures in time has a lot of security value that I can
demonstrate in terms of work function.
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp