[ale] Ouch Damnit. I am a victim of a gpg security attack
Charles Shapiro
hooterpincher at gmail.com
Wed Dec 1 16:36:16 EST 2021
Ah, this is so kool. I agree with you about version 2. I'm stripping
out references to 1.9, since it's not really germane any more. I
noticed that the SKS network is shut down. I've had pretty good luck
with keyserver.ubuntu.com, although I suspect that's not the ideal
place either. The mit key server (pgp.mit.edu) appears up but
slightly broken. I'd really like to be able to retain web of trust
data, since a) I think it's really cool and b) it is easy to explain.
I'm open to persuasion on this point though.
Would you like to look over what I have when I'm finished? I'd value
your input.
-- CHS
On Tue, Nov 30, 2021 at 11:41 PM Jeremy T. Bouse
<jeremy.bouse at undergrid.net> wrote:
>
> 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 evil32.com 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:
>
> ```
> /tmp/tmp.qutTUykczO/pubring.kbx
> -------------------------------
> pub rsa4096/0x46912F71D01E190C 2014-06-16 [SCEA]
> Key fingerprint = 1772 71A9 B587 2A70 54A8 4C62 4691 2F71 D01E 190C
> uid [ unknown] Jeremy T. Bouse <jeremy.bouse at undergrid.net>
>
> pub rsa4096/0x32B08BD14FADF197 2014-06-16 [SCEA]
> Key fingerprint = 5568 2662 AC57 EBB1 0E6C 04CE 32B0 8BD1 4FAD F197
> uid [ unknown] Jeremy T. Bouse (Debian Developer) <jbouse at debian.org>
> ```
>
> which is very different from when I run `gpg -k D01E190C 4FADF197` against my keyring where the output is as follows:
>
> ```
> pub rsa4096/0x15D0A62ED01E190C 2011-12-23 [SC]
> Key fingerprint = 653C 947B 2C05 481E 8A0A 9927 15D0 A62E D01E 190C
> uid [ultimate] Jeremy T. Bouse <jeremy.bouse at undergrid.net>
>
> pub rsa4096/0xFFCE1C9A4FADF197 2011-12-23 [SC]
> Key fingerprint = 09C5 AB71 078F 4ACD 235B 28E5 FFCE 1C9A 4FAD F197
> uid [ultimate] Jeremy T. Bouse (Debian Developer) <jbouse at debian.org>
> ```
>
> I also still had your old key from the last ALE key signing I attended... So again Evil32 vs the real deal shows...
>
> ```
> pub rsa2048/0xEFC2DFB41DF36586 2014-06-16 [SCEA]
> Key fingerprint = A4A6 6548 382D 0F35 F394 881F EFC2 DFB4 1DF3 6586
> uid [ unknown] Charles Shapiro (May replace 8C387D47) <charles.shapiro at tomshiro.org>
> ```
> vs
> ```
> pub rsa2048/0xB16965B51DF36586 2009-11-07 [SC]
> Key fingerprint = 7F1F C4C8 BA3E B464 49C2 42F2 B169 65B5 1DF3 6586
> uid [ unknown] Charles Shapiro (May replace 8C387D47) <charles.shapiro at tomshiro.org>
> ```
>
> This is why we verify fingerprints when doing our key signings :)
>
> 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.
>
> 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 https://key.openpgp.org 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.
>
> 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.
>
>
> On Tue, Nov 30, 2021 at 7:26 PM Charles Shapiro <hooterpincher at gmail.com> wrote:
>>
>> Ah, phew, I am Enlightened. So I don't need to actually revoke
>> 7f1f c4c8 ba3e b464 49c2 42f2 b169 65b5 1df3 6586. I just need to
>> make sure it's not confused with
>> a4a6 6548 382d 0f35 f394 881f efc2 dfb4 1df3 6586. ( note that the
>> last 8 digits of these key ids are identical).
>>
>> I'm still updating _Simple_How_To_ though. It's _way_ out of date.
>>
>> -- CHS
>>
>> On Tue, Nov 30, 2021 at 4:29 PM Jeremy T. Bouse via Ale <ale at ale.org> wrote:
>> >
>> > 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.
>> >
>> > On Tue, Nov 30, 2021 at 1:51 PM Steve Litt via Ale <ale at ale.org> wrote:
>> >>
>> >> Charles Shapiro via Ale said on Tue, 30 Nov 2021 12:19:01 -0500
>> >>
>> >>
>> >> >It turns out that someone had figured out a hash collision attack on
>> >> >32-bit key fingerprints back in 2016, then published a list of all
>> >> >the vulnerable fingerprints.
>> >>
>> >> Is there anything I can do to make myself less vulnerable to a hash
>> >> collision attack?
>> >>
>> >> Thanks,
>> >>
>> >>
>> >> SteveT
>> >>
>> >> Steve Litt
>> >> Spring 2021 featured book: Troubleshooting Techniques of the Successful
>> >> Technologist http://www.troubleshooters.com/techniques
>> >> _______________________________________________
>> >> Ale mailing list
>> >> Ale at ale.org
>> >> https://mail.ale.org/mailman/listinfo/ale
>> >> See JOBS, ANNOUNCE and SCHOOLS lists at
>> >> http://mail.ale.org/mailman/listinfo
>> >
>> > _______________________________________________
>> > Ale mailing list
>> > Ale at ale.org
>> > https://mail.ale.org/mailman/listinfo/ale
>> > See JOBS, ANNOUNCE and SCHOOLS lists at
>> > http://mail.ale.org/mailman/listinfo
More information about the Ale
mailing list