32bit key ids are not secure
I know there will some charge for your GPGtool larer on, are any of you aware of this?
,,32bit key ids are not secure
In the example below, a key is requested with its 32bit key id. The key server has two keys with the specified key id and GPG imports both keys. It is easy to generate and publish a key that looks identical if you only use 32 bits when specifying a key.,,
More info here: https://evil32.com/
Can you please comment.
Comments are currently closed for this discussion. You can start a new one.
|?||Show this help|
|ESC||Blurs the current field|
|r||Focus the comment reply box|
|^ + ↩||Submit the comment|
You can use
Command ⌘ instead of
Control ^ on Mac
Support Staff 1 Posted by Luke Le on 09 Jan, 2015 01:40 PM
we've answered this question in a different discussion:
Hope that helps.
2 Posted by Marcel on 08 Feb, 2015 05:01 PM
best practice is ALWAYS to check the full fingerprint of a key, because also 64 bit key IDs are trivially collidable, which is another potentially serious problem, see:
A lot of people are not aware that the 32 bit key ID and also the 64 bit key ID is visible in the full fingerprint of the key.
See as an example my actual business key:
Long Key ID: DFFE8DE31A7205F4
Short Key ID: 1A7205F4
As you can see the long and short key IDs are just the last 16 or 8 digits of its fingerprint respectively.
But I agree that we (and the GPGTools team) should think about how to make all this easily useable and secure for John Doe too.
Some of these 'best practice' suggestions will go into my new 'beginners manual' about the "GPGSuite & Yosemite", quoting:
"If you want to deal with a cryptographically-strong identifier for a key, you should use the full fingerprint. You should never rely on the short, or even long, Key ID."
All the best,
3 Posted by Peter Volek on 08 Feb, 2015 05:14 PM
Thank for writing back, I am a big support of yours in the arena. I will
follow the developments at GPGTools. I am glad there are people out here
questioning the ability of the current key structure and use.
Luke Le closed this discussion on 13 Feb, 2015 06:11 PM.