6 ms·

All the fake keys that I've seen mentioned are from the data set at https://evil32.com https://evil32.com. It appears a couple of researchers decided, back in

All the fake keys that I've seen mentioned are from the data set at https://evil32.com 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!

d33 10y ago
At this point this is INSANE that GnuPG still defaults to short IDs...
- pavanky 10y ago
  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..
  - satbyy 10y ago
    This bug report makes GPG to default to full fingerprint https://bugs.gnupg.org/gnupg/issue2379 https://bugs.gnupg.org/gnupg/issue2379
- snassar 10y ago
  It doesn't anymore. With GnuPG 2.1 listing of keys shows the fingerprint.
  - okket 10y ago
    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.
    - ajdlinux 10y ago
      Debian is currently switched to using gpg2 by default.
      - AceJohnny2 10y ago
        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/ 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/ https://lwn.net/subscribe/
    - snassar 10y ago
      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.
      - okket 10y ago
        > 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.
  - tedunangst 10y ago
    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.
  - ploxiln 10y ago
    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.
  - tomku 10y ago
    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.
- sneak 10y ago
  If you think that's crazy, don't look at the KDF it uses to generate a symmetric key from your passphrase. :D
deleted 10y ago
[deleted]
eridius 10y ago
If you haven't seen it yet, a co-creator of evil32 says (https://news.ycombinator.com/item?id=12298230 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.

d33 10y ago

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

pavanky 10y ago
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..
- satbyy 10y ago
  This bug report makes GPG to default to full fingerprint https://bugs.gnupg.org/gnupg/issue2379 https://bugs.gnupg.org/gnupg/issue2379
snassar 10y ago
It doesn't anymore. With GnuPG 2.1 listing of keys shows the fingerprint.
- okket 10y ago
  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.
  - ajdlinux 10y ago
    Debian is currently switched to using gpg2 by default.
    - AceJohnny2 10y ago
      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/ 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/ https://lwn.net/subscribe/
  - snassar 10y ago
    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.
    - okket 10y ago
      > 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.
- tedunangst 10y ago
  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.
- ploxiln 10y ago
  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.
- tomku 10y ago
  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.
sneak 10y ago
If you think that's crazy, don't look at the KDF it uses to generate a symmetric key from your passphrase. :D

deleted 10y ago

[deleted]

eridius 10y ago

If you haven't seen it yet, a co-creator of evil32 says (https://news.ycombinator.com/item?id=12298230 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.