Re: [openpgp] Fingerprints and their collisions resistance

[Andrey Jivsov <[e-mail]>]

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.
>
> 	Jon
>

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).