[ale] Ouch Damnit. I am a victim of a gpg security attack
Charles Shapiro
hooterpincher at gmail.com
Sat Jan 1 16:32:06 EST 2022
Okay phew. I think I am finished with everything I have to say. This
silly email server will not pass .tgz files along, so I
have stashed my work elsewhere. <http://tomshiro.org/gpg_howto.tgz> . I'd
love to see this replace the current contents of the gpg howto at
https://ale.org/static_pages/gpgstepbystep-131212.html .
-- CHS
On Wed, Dec 1, 2021 at 5:41 PM Jeremy T. Bouse <jeremy.bouse at undergrid.net>
wrote:
> 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/20220101/889435f7/attachment.htm>
More information about the Ale
mailing list