6 ms·

It seems like without fail, whenever PGP is mentioned, someone is ready to offer criticism of it, usually without offering a better alternative, since one doesn

It seems like without fail, whenever PGP is mentioned, someone is ready to offer criticism of it, usually without offering a better alternative, since one doesn't really exist. Yet it is the most stable, the most open, the most proven, and the most supported PKI technology, supporting both encryption and signatures. I found GnuPG and OpenPGP.js are incredibly easy to integrate into my project. I didn't like the current ways that it is used, so I designed a new way, with disposable private keys, which frees the user from key management burdens. I don't use many of PGP's features which I don't need, such as key management and nested keys. PGP is still an incredible standard and technology, the rare kind that's remained supported and (mostly) backwards-compatible for 25+ years, like HTML and Perl. I'm glad it exists, and I anticipate it being useful for at least another 25, thanks to the Lindy Effect.

dale_glass 3y ago
> It seems like without fail, whenever PGP is mentioned, someone is ready to offer criticism of it, usually without offering a better alternative, since one doesn't really exist.\ And arguably, it shouldn't exist. Modern thinking is that encryption is integral to a project and how it's implemented depends on what the project does. The old way is: Secure mail by passing it through PGP. Secure messages by passing them though PGP. Secure packages by passing them through PGP. The new way is: secure stuff by designing a system specific to what you need. So for instance, encrypting IM gives you the https://en.wikipedia.org/wiki/Signal_Protocol https://en.wikipedia.org/wiki/Signal_Protocol which has a whole bunch of complexity you wouldn't have for signing RPM packages because it needs it, while RPM doesn't.
- forgotmypw17 3y ago
  PGP is much more than email. It is a general-purpose text and binary encryption system with FOSS libraries and user-facing software for every major platform. It can be used for email, IM, package signing, authentication, and many other uses. And it is time-tested, with 25 years of library-building and 25 years of people trying to break it. Yes, it has many features which most projects don't need, and anyone is free to not use those features. Most documents I write do not include tables, but I would not argue that tables are an unnecessary feature. And same with PGP, I don't use most of its features, but I'm OK with them being there.
  - klodolph 3y ago
    25 years of people trying to figure out how to use it. I think the population of PGP users has some extreme selection pressure acting on it--it's a bunch of people who want security and don't care how bad the UX is.
    - bscphil 3y ago
      It's a bit like `git` in that yes, it is a complicated tool, but you can do 99% of what most people need to do with like 5 commands. People make exactly the argument you are making about git.
      - slondr 3y ago
        In fact I’d say gpg is even more singularly useful than git. Git has competitors which are superior to it in nearly every way; gpg does not, and likely won’t.
        dale_glass 3y ago
        GPG doesn't have competitors because modern security thought rejects the approach and treats it as a relic. The modern thought is that security can't be an add-on, it needs to be part of the system. So encryption for a chat client and encryption for a web browser, and signatures on a binary are all different problems to be solved differently.
      - klodolph 3y ago
        I have been using PGP a lot longer and still struggle to use it. When you say, "People make exactly the argument you are making about git," well, those people have a point. I use Git in spite of its usability problems because it gets useful work done. I don't see the upside of pushing through the usability problems of PGP. If I somehow put in the hours to get used to it, then what? What am I accomplishing?
  - morelisp 3y ago
    > It is a general-purpose text and binary encryption system That's exactly why it shouldn't exist!
- roundandround 3y ago
  I would consider verifying a signature with gpg, openssl or openssh a far more important feature for code signing than adding (equivalences of) ~transport features like OLM's ratcheting or perfect forward secrecy. If the only way to verify a package is to run code written by the same person who wrote the signing that's pretty bad.
  - dale_glass 3y ago
    But PGP sucks horribly for that! It's not made for it. Believe me, I tried. If you read the old PGP manuals, it talks about something like a woman secretly communicating with her lover. That's the use case, not verifying random packages. 0. GPG trusts your key absolutely. 1. GPG trusts the keys you've signed. 2. You can verify stuff people you trust trust. After that, you're stuck. So if you want to verify the signature on say, the Tor Browser then you either need to know the actual owner of the key (which just says "Tor Browser Developers"), or one of the people that signed it. I just tried, there's 100242 signatures on key 4E2C6E8793298290 for some reason. Probably an attack. So, what then? Well, GPG sucks here. You have no tools whatsoever to ask GPG "is there a path between me and this key?". There used to be some random guy that ran a web service, but that's gone. People have used GPG for signing random software, but GPG itself never actually adapted to this use case. The official tooling needed to solve the problem of "I need to make some sort of estimation of whether there's some sort of trust path between me and the signature of a random person I never met" doesn't exist. I guess you could use AWK to extract those 100K key IDs, download them all in a loop, import every single one (GPG will slow down to a crawl if you do that, it can't handle large keyrings), and hope that at least one has a signature from someone you know of it. Oh, and you better plan that kind of attempt well, because this will take hours, and GPG and related tooling will choke on such a huge keyring. So you need some sort of plan to import all that junk, find what you need, then get rid of the extra. Yeah, that's not usable. And I say that as somebody who participated in key signing parties to the point on having a key signed by a couple hundred people.
    - roundandround 3y ago
      Relying on web of trust is in contrast to having nothing. Other groups (Debian, Apache, etc) describe their hierarchy of trust inside or outside of the key servers, so I rarely care how messed up key server contents are. AFAIK language specific package managers fundamentally have a trust problem. If they cared enough to make a protocol they might care enough to fix the actual trust problem, but as it is, it is better that we can reuse tools and web of trust rather than download a tor browser and ask it to verify the next download of a tor browser..
arp242 3y ago
> It seems like without fail, whenever PGP is mentioned, someone is ready to offer criticism of it, usually without offering a better alternative, since one doesn't really exist. For signing minisign, signify, and OpenSSH exist; most of them have been around for quite a while (OpenSSH signing is the only one that's relatively new). They're not "alternatives to PGP" in the sense that they will do everything PGP can (notably, no encryption). But that's not really a bad thing, IMO, and for encryption alternatives exist too. One of the problems that ecosystem support is often lacking, both for signing and encryption. git can sign with OpenSSH since last year, but that's one of the exceptions. But that doesn't mean alternatives don't exist. Ecosystem support is hard; you need to convince untold authors of software to implement your new crypto thingymabob, and there's a "well, no one supports it yet, so why should I?" catch-22 here.
bscphil 3y ago
> without offering a better alternative On the one hand, I sort of agree with you, I think the disadvantages of current PGP tools are overstated. But I think there are some plausible alternatives depending on your use case. They just aren't bundled into a single tool. For file encryption, there's age. This uses all modern crypto and does authenticated encryption. For signing, there's signify. I wonder if age and signify can be made to use the same keys...? For live two-party encryption, there are protocols appropriate to the use case. Axolotl for chat, Wormhole for file transfers. For PKI, there's... whatever people actually do instead of PGP keyservers and WoT, because they've never been a reliable way to find out someone's public key. In practice, you'd either download it from someone's website, get it off a keyring, receive it through some other secure channel, or be given it in person. It's ironic that people make the argument "the reason no one uses PGP is that it doesn't have network effects, and the reason it can't build a network is that it sucks", because the thing keeping me on PGP is its network effects. In the circles I run in, you can count on people having PGP keys and knowing how to use them for encryption and signing. They've been used in Linux packaging for years, for example. I can't count on someone using age, at least not yet.
- savoyard 3y ago
  > For file encryption, there's age. This uses all modern crypto and does authenticated encryption. GnuPG offers AEAD encryption since version 2.3.0.
  - tptacek 3y ago
    Is it the default? That's all that matters. When GPG defaults to AEAD ciphers, you can say that the ecosystem really supports AEAD (GPG is the de facto reference implementation). If it's not the default, that's purely because too much of the installed base doesn't do AEAD --- there's no other reason to default to PGP's pitiful MDC construction.
  - upofadown 3y ago
    GnuPG has offered authenticated encryption for 20+ years now along with everything else that implements the OpenPGP standard.
jcranmer 3y ago
> Yet it is the most stable, the most open, the most proven, and the most supported PKI technology, supporting both encryption and signatures. You're completely ignoring the CA system used for TLS. In the niche segment of encrypted/signed email, S/MIME sees an order of magnitude or two more use than PGP. Even DNSSEC, for all its issues, is probably more used than PGP.
- tptacek 3y ago
  The other really obvious comparison is Signal, which secures more messages in a week than PGP/GPG has in its entire lifespan. I hate to have to point this out, but in the spirit of technical correctness: as bad as PGP is, it would still be a pretty big deal if it was totally broken (like, at the core, rather than its email use case, which Efail did catastrophically break). People would have to do things in response. But I maintain that if DNSSEC had a comparable failure, nobody would even need to be paged; literally nothing important meaningfully relies on it. It's almost perfectly performative.
  - forgotmypw17 3y ago
    Signal is controlled by one entity and supports 3.5 of the biggest platforms and does not provide libraries for third-party code. Most people who use Signal are getting a closed-source binary. I don’t see how it can even be compared to pgp.
    - tptacek 3y ago
      I don't see them as meaningful competitors either, but not for the reasons you're giving.
- forgotmypw17 3y ago
  CA is centralized and suffers from all the drawbacks of being such, including but not limited to censorship, lack of privacy, and centralization itself. I don’t understand how it can be even seen as an alternative to something like pgp

dale_glass 3y ago

> It seems like without fail, whenever PGP is mentioned, someone is ready to offer criticism of it, usually without offering a better alternative, since one doesn't really exist.\ And arguably, it shouldn't exist. Modern thinking is that encryption is integral to a project and how it's implemented depends on what the project does. The old way is: Secure mail by passing it through PGP. Secure messages by passing them though PGP. Secure packages by passing them through PGP. The new way is: secure stuff by designing a system specific to what you need. So for instance, encrypting IM gives you the https://en.wikipedia.org/wiki/Signal_Protocol https://en.wikipedia.org/wiki/Signal_Protocol which has a whole bunch of complexity you wouldn't have for signing RPM packages because it needs it, while RPM doesn't.

forgotmypw17 3y ago
PGP is much more than email. It is a general-purpose text and binary encryption system with FOSS libraries and user-facing software for every major platform. It can be used for email, IM, package signing, authentication, and many other uses. And it is time-tested, with 25 years of library-building and 25 years of people trying to break it. Yes, it has many features which most projects don't need, and anyone is free to not use those features. Most documents I write do not include tables, but I would not argue that tables are an unnecessary feature. And same with PGP, I don't use most of its features, but I'm OK with them being there.
- klodolph 3y ago
  25 years of people trying to figure out how to use it. I think the population of PGP users has some extreme selection pressure acting on it--it's a bunch of people who want security and don't care how bad the UX is.
  - bscphil 3y ago
    It's a bit like `git` in that yes, it is a complicated tool, but you can do 99% of what most people need to do with like 5 commands. People make exactly the argument you are making about git.
    - slondr 3y ago
      In fact I’d say gpg is even more singularly useful than git. Git has competitors which are superior to it in nearly every way; gpg does not, and likely won’t.
      - dale_glass 3y ago
        GPG doesn't have competitors because modern security thought rejects the approach and treats it as a relic. The modern thought is that security can't be an add-on, it needs to be part of the system. So encryption for a chat client and encryption for a web browser, and signatures on a binary are all different problems to be solved differently.
    - klodolph 3y ago
      I have been using PGP a lot longer and still struggle to use it. When you say, "People make exactly the argument you are making about git," well, those people have a point. I use Git in spite of its usability problems because it gets useful work done. I don't see the upside of pushing through the usability problems of PGP. If I somehow put in the hours to get used to it, then what? What am I accomplishing?
- morelisp 3y ago
  > It is a general-purpose text and binary encryption system That's exactly why it shouldn't exist!
roundandround 3y ago
I would consider verifying a signature with gpg, openssl or openssh a far more important feature for code signing than adding (equivalences of) ~transport features like OLM's ratcheting or perfect forward secrecy. If the only way to verify a package is to run code written by the same person who wrote the signing that's pretty bad.
- dale_glass 3y ago
  But PGP sucks horribly for that! It's not made for it. Believe me, I tried. If you read the old PGP manuals, it talks about something like a woman secretly communicating with her lover. That's the use case, not verifying random packages. 0. GPG trusts your key absolutely. 1. GPG trusts the keys you've signed. 2. You can verify stuff people you trust trust. After that, you're stuck. So if you want to verify the signature on say, the Tor Browser then you either need to know the actual owner of the key (which just says "Tor Browser Developers"), or one of the people that signed it. I just tried, there's 100242 signatures on key 4E2C6E8793298290 for some reason. Probably an attack. So, what then? Well, GPG sucks here. You have no tools whatsoever to ask GPG "is there a path between me and this key?". There used to be some random guy that ran a web service, but that's gone. People have used GPG for signing random software, but GPG itself never actually adapted to this use case. The official tooling needed to solve the problem of "I need to make some sort of estimation of whether there's some sort of trust path between me and the signature of a random person I never met" doesn't exist. I guess you could use AWK to extract those 100K key IDs, download them all in a loop, import every single one (GPG will slow down to a crawl if you do that, it can't handle large keyrings), and hope that at least one has a signature from someone you know of it. Oh, and you better plan that kind of attempt well, because this will take hours, and GPG and related tooling will choke on such a huge keyring. So you need some sort of plan to import all that junk, find what you need, then get rid of the extra. Yeah, that's not usable. And I say that as somebody who participated in key signing parties to the point on having a key signed by a couple hundred people.
  - roundandround 3y ago
    Relying on web of trust is in contrast to having nothing. Other groups (Debian, Apache, etc) describe their hierarchy of trust inside or outside of the key servers, so I rarely care how messed up key server contents are. AFAIK language specific package managers fundamentally have a trust problem. If they cared enough to make a protocol they might care enough to fix the actual trust problem, but as it is, it is better that we can reuse tools and web of trust rather than download a tor browser and ask it to verify the next download of a tor browser..

arp242 3y ago

> It seems like without fail, whenever PGP is mentioned, someone is ready to offer criticism of it, usually without offering a better alternative, since one doesn't really exist. For signing minisign, signify, and OpenSSH exist; most of them have been around for quite a while (OpenSSH signing is the only one that's relatively new). They're not "alternatives to PGP" in the sense that they will do everything PGP can (notably, no encryption). But that's not really a bad thing, IMO, and for encryption alternatives exist too. One of the problems that ecosystem support is often lacking, both for signing and encryption. git can sign with OpenSSH since last year, but that's one of the exceptions. But that doesn't mean alternatives don't exist. Ecosystem support is hard; you need to convince untold authors of software to implement your new crypto thingymabob, and there's a "well, no one supports it yet, so why should I?" catch-22 here.

bscphil 3y ago

> without offering a better alternative On the one hand, I sort of agree with you, I think the disadvantages of current PGP tools are overstated. But I think there are some plausible alternatives depending on your use case. They just aren't bundled into a single tool. For file encryption, there's age. This uses all modern crypto and does authenticated encryption. For signing, there's signify. I wonder if age and signify can be made to use the same keys...? For live two-party encryption, there are protocols appropriate to the use case. Axolotl for chat, Wormhole for file transfers. For PKI, there's... whatever people actually do instead of PGP keyservers and WoT, because they've never been a reliable way to find out someone's public key. In practice, you'd either download it from someone's website, get it off a keyring, receive it through some other secure channel, or be given it in person. It's ironic that people make the argument "the reason no one uses PGP is that it doesn't have network effects, and the reason it can't build a network is that it sucks", because the thing keeping me on PGP is its network effects. In the circles I run in, you can count on people having PGP keys and knowing how to use them for encryption and signing. They've been used in Linux packaging for years, for example. I can't count on someone using age, at least not yet.

savoyard 3y ago
> For file encryption, there's age. This uses all modern crypto and does authenticated encryption. GnuPG offers AEAD encryption since version 2.3.0.
- tptacek 3y ago
  Is it the default? That's all that matters. When GPG defaults to AEAD ciphers, you can say that the ecosystem really supports AEAD (GPG is the de facto reference implementation). If it's not the default, that's purely because too much of the installed base doesn't do AEAD --- there's no other reason to default to PGP's pitiful MDC construction.
- upofadown 3y ago
  GnuPG has offered authenticated encryption for 20+ years now along with everything else that implements the OpenPGP standard.

jcranmer 3y ago

> Yet it is the most stable, the most open, the most proven, and the most supported PKI technology, supporting both encryption and signatures. You're completely ignoring the CA system used for TLS. In the niche segment of encrypted/signed email, S/MIME sees an order of magnitude or two more use than PGP. Even DNSSEC, for all its issues, is probably more used than PGP.

tptacek 3y ago
The other really obvious comparison is Signal, which secures more messages in a week than PGP/GPG has in its entire lifespan. I hate to have to point this out, but in the spirit of technical correctness: as bad as PGP is, it would still be a pretty big deal if it was totally broken (like, at the core, rather than its email use case, which Efail did catastrophically break). People would have to do things in response. But I maintain that if DNSSEC had a comparable failure, nobody would even need to be paged; literally nothing important meaningfully relies on it. It's almost perfectly performative.
- forgotmypw17 3y ago
  Signal is controlled by one entity and supports 3.5 of the biggest platforms and does not provide libraries for third-party code. Most people who use Signal are getting a closed-source binary. I don’t see how it can even be compared to pgp.
  - tptacek 3y ago
    I don't see them as meaningful competitors either, but not for the reasons you're giving.
forgotmypw17 3y ago
CA is centralized and suffers from all the drawbacks of being such, including but not limited to censorship, lack of privacy, and centralization itself. I don’t understand how it can be even seen as an alternative to something like pgp