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).
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp