[Top] [All Lists]

Re: [openpgp] Fingerprints and their collisions resistance

2013-01-04 00:25:59
On 3/01/13 19:17 PM, Jon Callas wrote:
The proposal that we had a long time ago which was essentially prefix a hash 
with an algorithm number was a good one. I remember everyone thinking it was a 
good idea and no one belling the cat. I vaguely remember someone writing up an 
I-D on it, too.

That's the way I'd go, as it's future-proofed.

If we have to have hash agility, I agree that's a good way to do it.

Alternatively we can do OIDs in which case we will generate arguments, external dependencies and work for ourselves for generations -- over on another list some were arguing recently about whether Taiwan was allowed to use this OID or that OID for their root key, Taiwan being one of those not-a-countries, and everyone arguing being not-those-authorities.

Hence my earlier question - has anyone allocated the OpenPGP numbers for Keccak as yet? The reason I asked is because I stumbled on the code last week and thought what a fine idea it would be to at least prepare the way.... Strawman?

  SHA3-224         4        12
  SHA3-256         5        13
  SHA3-384         6        14
  SHA3-512         7        15

Strawman? I'm not sure why there is a gap 4-7 in rfc4880. Are there any spots already allocated?

Another question, back on the fingerprints. If we end up doing a hash-agile fingerprint, how does the algorithm number get laid out by the users on their business cards?

E.g., can we agree on a one byte number, values 0 to 7F, with leading bit reserved for future escape valve?

Then, if it is to be written out, this would mean a "new-style fingerprint" is always an odd number of bytes. Could we agree on a stylistic convention? Something like:

  7F-- AB01 CD23 EF45 ...

Just thinking aloud. Are there any other practical ramifications of going to an agile fingerprint?

openpgp mailing list