[ale] Ouch Damnit. I am a victim of a gpg security attack
Jeremy T. Bouse
jeremy.bouse at undergrid.net
Tue Nov 30 23:41:14 EST 2021
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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.ale.org/pipermail/ale/attachments/20211130/c915b82d/attachment.htm>
More information about the Ale
mailing list