Some comments...
On 4/01/13 02:30 AM, Andrey Jivsov wrote:
On 01/03/2013 02:54 PM, Werner Koch wrote:
On Thu, 3 Jan 2013 20:06, openpgp(_at_)brainhub(_dot_)org said:
...
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
Except that SHA-2 is already in use and has hardware support.
... but there is no reason why SHA-3 will not optimized in the future.
BTW, which SHA-2 friendly CPU feature we are talking about? ( other than
Intel's plans to add cycle shift )
In any case, please note that we are talking about hashing the key
material and thus the performance of the hash algorithm doesn't matter.
My preference for SHA-3 is to satisfy the concerns of algorithm agility.
I argue for a hardcoded algorithm, and thus the natural choice is the
strongest of SHA that will be future-proof for regulatory compliance.
I would also be OK to do SHA-2 + SHA-3, TLS style, to be future proof,
but this seems too paranoid.
It also seems non-sensical, the notion that anyone is likely to trash
SHA-2 or SHA-3 over the next decade has been well and truly trounced. I
don't think we really have to worry about the hardness of this
particular application overly muchly.
Meanwhile, spending time on that means they weren't spending time on
other more important things. Maybe a warning to us!
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
So why should we truncate the fingerprint? Is there a reason to believe
that truncation to 160 bit of SHA-2 or SHA-3 is seriously more secure
than SHA-1? I don't know.
The current attacks tell us so. Instead of 80 bit is security (birthday
bounds) SHA-1 is listed as 51 bits on
http://en.wikipedia.org/wiki/Message_digest. The number can continue to
go lower.
But I also think that it makes sense to standardise on larger than 160
bits of the fingerprint as a UI feature (somewhere between 160 and 384
bits).
If the purpose of the fingerprint is *only* for human comparisons, then
it would seem that this is a marginal improvement. But if it falls out
of other decisions, oh well, maybe.
strength for regulatory compliance. Consider not hashing the key
creation date. Fixing all the variables in this paragraph, we have the
What would be the advantage of this except for yet another code path.
signed message, but I don't think they materially care about the
flavour of the fingerprint (as long as it's a "strong" one).
They will care if a key suddenly comes with two different fingerprints.
We never had this situation in OpenPGP. Recall how long it took to get
rid of v3 keys. Thus if we want a new fingerprint algorithm we need to
change more than just this.
While every key inherently will have two fingerprints -- old and new
(and I was saying don't make it worse with hash variations) -- the
software should probably select to display only one of them with an
option to change it.
It doesn't need to be so. If the switch to some other algorithm is
organised in alignment with a new key type, then it can roll over with
the new key type.
(Whether this is overall better or worse depends...)
We might let users enter the fingerprint as before but then use it for
dual purpose as SHA-1 or new one (as opposed to using an explicit type).
At some point in the future one might start flagging links achieved with
the old fingerprint. Features flags will be helpful for this (i.e. I
generate a key that I want to be known only by its new fingerprint; I
put this fact into Features; don't match this key by the old fingerprint)
those Features seem like User and Code Confusion :)
iang
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp