keyids are not a security feature

Posted Aug 30, 2016 10:27 UTC (Tue) by dd9jn (✭ supporter ✭, #4459)
In reply to: keyids are not a security feature by robbe
Parent article: A different sort of "Fake Linus Torvalds"

If you put "keyid-format long" into gpg.conf --list-sigs shows the long keyids. That is unfortunately all the data we have in the current OpenPGP specs. Yes, we can't reject short keyids as input to --recv-key. There are even valid use cases, like private key servers of companies.

a) --with-colons exists since 0.2.12 (early 1998) and the format as always been backward compatible.

b) The problem is that there are many non-public systems which might update gpg at some point and would then break.

keyids are not a security feature

Posted Aug 31, 2016 2:57 UTC (Wed) by eduard.munteanu (guest, #66641) [Link] (1 responses)

Long keyids aren't safe either (even fingerprints are kinda weak), so it's rather pointless to urge people into a short-term fix. Perhaps it's time to break compatibility on purpose, because the standard is broken. So what if some non-public installation breaks, is it really any better if it ends up silently compromised at some point?

keyids are not a security feature

Posted Aug 31, 2016 6:14 UTC (Wed) by dd9jn (✭ supporter ✭, #4459) [Link]

Please give a reference for your statement that fingerprints are weak. Keep in mind that all cryptographers agree that SHA-1 is resistant to pre-image attacks; it will eventually be possible to create collisions but that is irrelevant for the use case of fingerprints. Further the OpenPGP WG is working on updates to the standard including an update on the fingerprint algorithm. In any case there is no need for a fix - the evil32 thing is merely an annoyance but not at all a security problem; same would hold true for an evil64.