tag:gpgtools.tenderapp.com,2011-11-04:/discussions/feedback/1104-32bit-key-ids-are-not-secureGPGTools: Discussion 2018-10-18T19:55:57Ztag:gpgtools.tenderapp.com,2011-11-04:Comment/356674652014-12-31T12:23:23Z2014-12-31T12:23:24Z32bit key ids are not secure<div><p>Hi,</p>
<p>I know there will some charge for your GPGtool larer on, are any
of you aware of this?</p>
<p>,,32bit key ids are not secure</p>
<p>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.,,</p>
<p>More info here: <a href=
"https://evil32.com/">https://evil32.com/</a></p>
<p>Can you please comment.</p></div>Petertag:gpgtools.tenderapp.com,2011-11-04:Comment/356674652015-01-09T13:40:43Z2015-01-09T13:40:43Z32bit key ids are not secure<div><p>Hi Peter,</p>
<p>we've answered this question in a different discussion:<br>
<a href=
"http://support.gpgtools.org/discussions/feedback/1126-how-many-bits-are-gpg-keys-does-32-bit-collision-problem-affect-gpgtools">
http://support.gpgtools.org/discussions/feedback/1126-how-many-bits...</a></p>
<p>Hope that helps.</p></div>Luke Letag:gpgtools.tenderapp.com,2011-11-04:Comment/356674652015-02-08T17:01:35Z2015-02-12T14:34:36Z32bit key ids are not secure<div><p>Hi Peter,</p>
<p>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:</p>
<p><a href=
"http://thread.gmane.org/gmane.ietf.openpgp/7413">http://thread.gmane.org/gmane.ietf.openpgp/7413</a></p>
<p>and</p>
<p><a href=
"https://www.debian-administration.org/users/dkg/weblog/105">https://www.debian-administration.org/users/dkg/weblog/105</a></p>
<p>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.</p>
<p>See as an example my actual business key:</p>
<p>Fingerprint: ce633cc5d5d71455f9cd5693dffe8de31a7205f4<br>
Long Key ID: DFFE8DE31A7205F4<br>
Short Key ID: 1A7205F4</p>
<p>As you can see the long and short key IDs are just the last 16
or 8 digits of its fingerprint respectively.</p>
<p>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.</p>
<p>Some of these 'best practice' suggestions will go into my new
'beginners manual' about the "GPGSuite & Yosemite",
quoting:</p>
<p>"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."</p>
<p>source: <a href=
"https://help.riseup.net/en/security/message-security/openpgp/best-practices#dont-rely-on-the-key-id">
https://help.riseup.net/en/security/message-security/openpgp/best-p...</a></p>
<p>All the best,<br>
Marcel</p></div>Marceltag:gpgtools.tenderapp.com,2011-11-04:Comment/356674652015-02-08T17:14:53Z2015-02-08T17:14:53Z32bit key ids are not secure<div><p>Hi Marcel,</p>
<p>Thank for writing back, I am a big support of yours in the
arena. I will<br>
follow the developments at GPGTools. I am glad there are people out
here<br>
questioning the ability of the current key structure and use.</p>
<p>Regards</p>
<p>Peter</p></div>Peter Volek