<div dir="ltr">Precisely... My GPG keys have been part of the strong set of global keys largely in part to my involvement with Debian. To illustrate what I'm talking about I downloaded the tarball from the <a href="http://evil32.com">evil32.com</a> site and extracted it. I then created a temporary GPG directory using `export GPGHOME=$(mktemp -d)` and once I changed into the cloneset/ directory that was created I ran `gpg --import *D01E190C.pgp *4FADF197.pgp` which are the 32-bit hash collisions for my Debian and Personal GPG keys. Once they were imported into a clean keyring I ran `gpg -k` after copying my ~/.gnupg/pgp.conf to $GNUPGHOME the output was as follows:<div><br></div><div>```</div><div>/tmp/tmp.qutTUykczO/pubring.kbx<br>-------------------------------<br>pub   rsa4096/0x46912F71D01E190C 2014-06-16 [SCEA]<br>      Key fingerprint = 1772 71A9 B587 2A70 54A8  4C62 4691 2F71 D01E 190C<br>uid                   [ unknown] Jeremy T. Bouse <<a href="mailto:jeremy.bouse@undergrid.net">jeremy.bouse@undergrid.net</a>><br><br>pub   rsa4096/0x32B08BD14FADF197 2014-06-16 [SCEA]<br>      Key fingerprint = 5568 2662 AC57 EBB1 0E6C  04CE 32B0 8BD1 4FAD F197<br>uid                   [ unknown] Jeremy T. Bouse (Debian Developer) <<a href="mailto:jbouse@debian.org">jbouse@debian.org</a>><br></div><div>```</div><div><br></div><div>which is very different from when I run `gpg -k D01E190C 4FADF197` against my keyring where the output is as follows:<br><br></div><div>```</div><div>pub   rsa4096/0x15D0A62ED01E190C 2011-12-23 [SC]<br>      Key fingerprint = 653C 947B 2C05 481E 8A0A  9927 15D0 A62E D01E 190C<br>uid                   [ultimate] Jeremy T. Bouse <<a href="mailto:jeremy.bouse@undergrid.net">jeremy.bouse@undergrid.net</a>><br><br>pub   rsa4096/0xFFCE1C9A4FADF197 2011-12-23 [SC]<br>      Key fingerprint = 09C5 AB71 078F 4ACD 235B  28E5 FFCE 1C9A 4FAD F197<br>uid                   [ultimate] Jeremy T. Bouse (Debian Developer) <<a href="mailto:jbouse@debian.org">jbouse@debian.org</a>></div><div>```<br></div><div><br>I also still had your old key from the last ALE key signing I attended... So again Evil32 vs the real deal shows...</div><div><br></div><div>```</div><div>pub   rsa2048/0xEFC2DFB41DF36586 2014-06-16 [SCEA]<br>      Key fingerprint = A4A6 6548 382D 0F35 F394  881F EFC2 DFB4 1DF3 6586<br>uid                   [ unknown] Charles Shapiro (May replace 8C387D47) <<a href="mailto:charles.shapiro@tomshiro.org">charles.shapiro@tomshiro.org</a>><br></div><div>```</div><div>vs</div><div>```</div><div>pub   rsa2048/0xB16965B51DF36586 2009-11-07 [SC]<br>      Key fingerprint = 7F1F C4C8 BA3E B464 49C2  42F2 B169 65B5 1DF3 6586<br>uid                   [ unknown] Charles Shapiro (May replace 8C387D47) <<a href="mailto:charles.shapiro@tomshiro.org">charles.shapiro@tomshiro.org</a>><br></div><div>```</div><div><br></div><div>This is why we verify fingerprints when doing our key signings :)</div><div><br></div><div>As for updating the simple howto page... I agree it is vastly out of date. Generally, you'd want to be making use of GnuPG v2, not v1 for starters as it has a much better security footprint removing some potential memory leakage points in the older version. Another nice side effect of using GPG2 for key generation for someone who doesn't have a key already is that it automatically creates a revocation certificate and saves it under ~/.gnugpg/openpgp-revocs.d/ directory.</div><div><br></div><div>One update that might be good to mention is that with the SKS key server network all but shutdown, and the Hagrid key server used by <a href="https://key.openpgp.org">https://key.openpgp.org</a> is that it 1) does not gossip and share keys along through a network, 2) requires you to validate your email to make your key available, 3) it strips all signatures except self-signed signatures so it can't be used for web of trust calculations. For this you ideally would want to either distribute an export of your public key at a location or set up WKD if you have your own domain.</div><div><br></div><div>P.S. - I did strip out the subkeys out from the above real key outputs for both CHS and my keys as that was not part of the Evil32 cloneset data.</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Nov 30, 2021 at 7:26 PM Charles Shapiro <<a href="mailto:hooterpincher@gmail.com">hooterpincher@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Ah, phew, I am Enlightened. So I don't need to actually revoke<br>
7f1f c4c8 ba3e b464 49c2 42f2 b169 65b5 1df3 6586.  I just need to<br>
make sure it's not confused with<br>
a4a6 6548 382d 0f35 f394 881f efc2 dfb4 1df3 6586.  ( note that the<br>
last 8 digits of these key ids are identical).<br>
<br>
I'm still updating _Simple_How_To_ though.  It's _way_ out of date.<br>
<br>
-- CHS<br>
<br>
On Tue, Nov 30, 2021 at 4:29 PM Jeremy T. Bouse via Ale <<a href="mailto:ale@ale.org" target="_blank">ale@ale.org</a>> wrote:<br>
><br>
> To be more precise, your key is not vulnerable unless, of course, you lose control of the private key data itself. The vulnerability showed that a new key could be generated that would cause a 32-bit short key-id hash collision. It pointed out that an erroneous key could be returned by simply requesting keys via the 32-bit short key-id. If you look closely at your key and the key in the vulnerable list, the actual full fingerprint does not match; however, if you only request by the short key-id rather than the long key-id or the full fingerprint you could have the wrong key returned. Your key isn't affected other than the confusion caused by retrieving the key using the short key-id. This is a prime example of why you verify the complete fingerprint of the key before signing a key.<br>
><br>
> On Tue, Nov 30, 2021 at 1:51 PM Steve Litt via Ale <<a href="mailto:ale@ale.org" target="_blank">ale@ale.org</a>> wrote:<br>
>><br>
>> Charles Shapiro via Ale said on Tue, 30 Nov 2021 12:19:01 -0500<br>
>><br>
>><br>
>> >It turns out that someone had figured out a hash collision attack on<br>
>> >32-bit key fingerprints back in 2016,  then published a list of all<br>
>> >the vulnerable fingerprints.<br>
>><br>
>> Is there anything I can do to make myself less vulnerable to a hash<br>
>> collision attack?<br>
>><br>
>> Thanks,<br>
>><br>
>><br>
>> SteveT<br>
>><br>
>> Steve Litt<br>
>> Spring 2021 featured book: Troubleshooting Techniques of the Successful<br>
>> Technologist <a href="http://www.troubleshooters.com/techniques" rel="noreferrer" target="_blank">http://www.troubleshooters.com/techniques</a><br>
>> _______________________________________________<br>
>> Ale mailing list<br>
>> <a href="mailto:Ale@ale.org" target="_blank">Ale@ale.org</a><br>
>> <a href="https://mail.ale.org/mailman/listinfo/ale" rel="noreferrer" target="_blank">https://mail.ale.org/mailman/listinfo/ale</a><br>
>> See JOBS, ANNOUNCE and SCHOOLS lists at<br>
>> <a href="http://mail.ale.org/mailman/listinfo" rel="noreferrer" target="_blank">http://mail.ale.org/mailman/listinfo</a><br>
><br>
> _______________________________________________<br>
> Ale mailing list<br>
> <a href="mailto:Ale@ale.org" target="_blank">Ale@ale.org</a><br>
> <a href="https://mail.ale.org/mailman/listinfo/ale" rel="noreferrer" target="_blank">https://mail.ale.org/mailman/listinfo/ale</a><br>
> See JOBS, ANNOUNCE and SCHOOLS lists at<br>
> <a href="http://mail.ale.org/mailman/listinfo" rel="noreferrer" target="_blank">http://mail.ale.org/mailman/listinfo</a><br>
</blockquote></div>