Hacker News new | past | comments | ask | show | jobs | submit login

All the fake keys that I've seen mentioned are from the data set at https://evil32.com.

It appears a couple of researchers decided, back in 2014, to demonstrate this issue by cloning the entire strong set of the PGP web of trust (not just Linus' key, but basically everyone who uses PGP/GPG for Free Software development - myself included).

It would appear that sometime quite recently, someone decided it would be fun to upload all of those keys (there's ~24,000 in their tarball) to the keyservers...

One would hope that the researchers behind evil32.com are ethical enough and sensible enough to have permanently destroyed the secret keys - but obviously, anyone could mount this attack quite trivially with modern hardware.

So, check your fingerprints!




If you haven't seen it yet, a co-creator of evil32 says (https://news.ycombinator.com/item?id=12298230) that they found an old local backup of the secret keys and generated revocation certificates for all of the keys, and further promises that the secret keys never left that machine and will never use them for anything beyond the revocation certificates.


At this point this is INSANE that GnuPG still defaults to short IDs...


It doesn't anymore.

With GnuPG 2.1 listing of keys shows the fingerprint.


But for server installations (auto-signing, checking, etc.) you are often directed to GnuPG 1 because "less dependencies". Also "apt install gnupg" / "dnf install gnupg" both give you version 1 on the most recent Ubuntu/Fedora.

For desktop usage many prefer GnuPG 2.0, because they fear compatibility issues that the new 2.1 key storage format could have with 3rd party software, and you can't go back (at least this is the reason why the Homebrew maintainers still default to 2.0, but at least not to version 1 anymore since a few days).

So you have a mess of 3 stable versions, all used by many at the same time.


I don't know where people would run three versions at the same time. The information from the GnuPG project is clear: You can run GnuPG 1.x and GnuPG 2.x at the same time, but you should not have GnuPG 2.0 and GnuPG 2.1 installed at the same time, as bad things might happen.

What 3rd party software is using the keystorage mechanisms directly? Do you mean how information is output from GnuPG?

It sounds like the situation you are describing is the keystore, which has changed formats. GnuPG 2.1, as far as I can remember, will oll use the older versions keystore, but you are correct, once you have a 2.1 keystore it can't be used by GnuPG 2.0 and 1.x.

It's a tough call for the GnuPG developers and something distributions should help with. On one hand there is immense pressure to improve GnuPG, on the other hand, you have many actors who kick GnuPG around when it makes any deviation.

I would say defaulting to GnuPG 1.x is a bug and new releases of Linux, Homebrew, etc., should use GnuPG 2.0 at the very least, but better yet, use GnuPG 2.1 which has many of the things that people complain about fixed or in process of being fixed.


> I don't know where people would run three versions at the same time.

Not on the same machine, but server/automatic -> GnuPG 1, desktop 2.0 or 2.1. Also different people may run different versions, even GnuPG 1 on desktop because they are used to. This compatibility mess that seems to persist for while was what I meant why people prefer to use the lowest common denominator in their sigs/cards/slides -> evil32.

> What 3rd party software is using the keystorage mechanisms directly?

Aren't there any? Good, then I misunderstood that argument in the Homebrew debates I read, sorry. That leaves only the fear of automatic upgrading and the inability to downgrade again as a blocker.


In practice you can use all three versions of GnuPG on three different devices without a particular difference. One problem you might see is if you are using the newer experimental curve-based algorithms on a computer running GnuPG 1.4 and you get blocked, but you really ought not to do that anyway.

As for the downgrading issue:

It used to be you could just copy your .gnupg directory from computer to computer to computer and that's what constituted migrating your PGP keys.

This was also true for moving frmo GnuPG 1.4 to GnuPG 2.x. If you are starting with a new GnuPG keystore from 2.1 you can't just copy .gnupg and use it in a GnuPG 1.4 system, you have to export your public keys, your private keys, and your trustdb (although I am iffy on what this does) and import them on the systems where you are running GnuPG 1.4 or 2.0

I am unaware of any 3rd party software directly accessing the GnuPG keystore, but that doesn't say much.


Debian is currently switched to using gpg2 by default.


Debian is in the process of switching to using gpg2 by default.

Here's this week's LWN article about it:

https://lwn.net/SubscriberLink/696561/6392ebc623b794d8/

Note that it's a subscriber-generated link (articles <1wk old are paywalled). Please consider funding LWN's excellent work by becoming a subscriber: https://lwn.net/subscribe/


> For desktop usage many prefer GnuPG 2.0, because they fear compatibility issues that the new 2.1 key storage format could have with 3rd party software

Any idea what this will mean for Yubikey users? I've been wanting to set up my Yubikey 4 for GPG for a while, and have been... daunted.


It's insane that it ever defaulted to short IDs, the insecurity of which was not just known, but proven by demonstration, years before GnuPG was released.


If you use gnupg 2.0.x, you can set "keyid-format long" in your gpg.conf to get 64-bit key IDs (instead of the classic 32-bit ones). Not really good enough, but a reasonably effective short-term stop-gap measure. IMHO.


Worth noting for any Mac users, the version of gpg2 available by default in Homebrew is 2.0.30. If you want 2.1 you can install it from Homebrew/homebrew-versions/gpg21 at the risk of possibly breaking other formula that expect 2.0.


If you think that's crazy, don't look at the KDF it uses to generate a symmetric key from your passphrase. :D


I remember reading that they updated it to be full key a few versions ago. I can't seem to find the actual link for that..


This bug report makes GPG to default to full fingerprint

https://bugs.gnupg.org/gnupg/issue2379




Consider applying for YC's Fall 2025 batch! Applications are open till Aug 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: