[ale] Ouch Damnit. I am a victim of a gpg security attack
Jeremy T. Bouse
jeremy.bouse at undergrid.net
Wed Dec 1 17:41:48 EST 2021
Keyserver.ubuntu.com is running Hockeypuck which is similar to SKS. I know
some of the SKS key server operators switched to run Hockeypuck, I did not.
Pgp.mit.edu started out running the old key server but I think it switched
to SKS and may be experiencing the same issues that caused may of the SKS
key server operators to shutdown as it became more work for the effort.
Setting up WKD is not that hard to do. I'm hosting mine in AWS as it is
really static and I just have a CI/CD pipeline to update when I need to.
The Web of Trust was really the original way of establishing trust between
keys. The whole Bob & Alice key exchange when you know one party and trust
them to be an introducer. I really don't like the way Hagrid strips the
signatures because it doesn't allow retrieving a key with all the
signatures to know if I should trust a key based on who has signed it.
I'll definitely take a look over the doc after you've made your revisions.
I definitely don't follow the "simple" key management but I can check for
any key pieces that should be in.
On Wed, Dec 1, 2021 at 4:36 PM Charles Shapiro <hooterpincher at gmail.com>
wrote:
> 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
>
--
OpenPGP Key Proofs
<https://metacode.biz/openpgp/key#0x653C947B2C05481E8A0A992715D0A62ED01E190C>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.ale.org/pipermail/ale/attachments/20211201/caa5f8a3/attachment.htm>
More information about the Ale
mailing list