On 05/29/2012 02:18 PM, David Shaw wrote: > The reason I bring it up is that using the v3 key attack, 64-bit key IDs have > no particular benefit over 32-bit IDs for intentional collisions (i.e. an > attacker generating a key with the same key ID as the victim in order to > confuse matters and/or steal traffic). It's just as easy to forge 64 bits as > it is to forge 32…
Right, which is why gpg should default to not processing/accepting v3
keys either, frankly. The window for v3 being deprecated started long
ago. If we expect people to rely on gpg for any sort of key management,
it ought to have reasonably safe and sane defaults.
dropping v3 unless explicitly overridden, and defaulting to displaying
64-bit keyids in the places where it must show keyids seems like it
would be a reasonable choice.
Yes, it might break compatibility with some existing docs. Those docs
are likely to be out-of-date, and many of them may well encourage bad
practices anyway to someone who doesn't understand what they're seeing.
fwiw, i agree with Werner that we should avoid displaying keyids to
users wherever we can -- they're not human-friendly identifiers. But if
we're going to expose them, we should be exposing them in ways that at
least make them somewhat collision-resistant.
--dkg
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
