[Top] [All Lists]

Re: [openpgp] Fingerprints and their collisions resistance

2013-01-03 13:06:29
On 01/03/2013 08:17 AM, 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.


I am a big fan of algorithm agility myself, but I have a difficult time justifying the additional complexity that the new *suite* of the fingerprints would bring v.s. just one new fingerprint algorithm.

Compare the situation with the AES. There are 3 AES sizes and other ciphers in use. Other ciphers exist as legacy ciphers that preceded AES or for regulatory reasons. 3 AES sizes exist for performance reasons.

None of these concerns apply for the new algorithm we are introducing ( we have clarity of future strength, small input for hashing, no export/import control of encryption). Fingerptins are special data structures because they are sometimes input by humans.

We now have SHA-3, which is good for a few decades ( and also SHA-2s are not so bad ).

Here is a more technical description, to be specific:

Let's say we choose SHA-3-384, which is no more difficult to implement than SHA-2. We then simply use the current fingerprint algorithm but instead of SHA-1 use SHA-3-384. Then allow truncation of the output (it's already implied by the 8 byte keyIDs). 20 byte fingerprint on a business card may be reasonable, but we also would like to have full strength for regulatory compliance. Consider not hashing the key creation date. Fixing all the variables in this paragraph, we have the new single fingerprint algorithm.

To put it differently, users may care about the hash associated with a signed message, but I don't think they materially care about the flavour of the fingerprint (as long as it's a "strong" one).

openpgp mailing list

<Prev in Thread] Current Thread [Next in Thread>