7 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 doe

> 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!
  - SpaghettiCthulu 3y ago
    But why?
    - dale_glass 3y ago
      Because security is a serious problem that needs to be treated seriously for it to be useful. You can't just sprinkle it on an existing system like fairy dust, it has to be built into the design to be effective, and it needs to be periodically re-thought mercilessly. PGP for instance encourages some terrible habits, like awfully long lived keys. You have somebody signing packages with an ancient DSA-1024 key, perhaps because "SQUEE Philip Zimmermann himself signed that key back in 1996 and I can't part with it". That's not the right attitude to security. Good security requires a solution fit to whatever specific thing you need to secure, a system designed with it in mind, and a lack of sentimentality and backwards compatibility.
      - SpaghettiCthulu 3y ago
        I completely agree with your points but you seem to be missing the point which is: why does OpenPGP's versatility make it a bad candidate?
        morelisp 3y ago
        It is not versatile - multi-purpose - it is weak - general-purpose. "Encrypt/sign these bytes with this cipher, these parameters, and this key" is the least common denominator of cryptographic ability and ignores all the work to build an actual useful cryptographic system around it. On top of this, its specific interfaces for doing that suck, so you can't even bury it as a safe "primitive" in whatever system you're trying to build (even assuming you wanted to bring in the attack surface of a 25 year old C project). Something like libsodium is actually versatile in that it offers primitives to build a broad set of safe tools on top of. It does more by doing less.
- tptacek 3y ago
  In general, for each major use case of file/message encryption (messaging, backup, transport, package signing, contracts, drive/filesystem encryption, &c), there is a cryptosystem that does the job better than PGP, in part by being built out of modern components and a modern understanding of cryptography†, and in part by being designed around the actual problem and not a lossy abstraction of the problem. So it's frustrating to see PGP advocates talking about these things PGP does that Signal, or Tarsnap, or Minisign, or Certificate Transparency, or whatever don't do on their own. It's like telling a line cook that a Swiss Army Knife is a meaningful competitor to a chef's knife. Like: it doesn't matter, nobody's going to use a Swiss Army Knife on the line, it's not a threat or anything, but it's so obviously wrong. † People tend to forget how underdeveloped our understanding of cryptography engineering was when PGP/GPG first came about; for a crash course, check out the IETF archives of Rogaway pleading with the IPSEC people to avoid chained CBC IVs.
  - forgotmypw17 3y ago
    I don’t understand how having multiple tools, each one needing audits and effort and time to make secure, each one needing porting to all the platforms that people use, each one breaking compatibility with legacy platforms and hardware, is better than an existing tool without any of these drawbacks.
    - donaldstufft 3y ago
      Because the existing tool does a bad job at all of them, and those tools do reasonably good jobs at each of their respective tasks. Fundamentally the things you want from a secure crypto system differ depending on the context in which you're applying it. Email needs different things than package signing does than file encryption does. It's silly to pretend that the same tool can provide a good and secure experience for all of them.
      - forgotmypw17 3y ago
        I don’t think it’s that silly, and I don’t think email is that different from packages is that different from files. They’re all data with some attributes, and pgp handles them nicely, if you can write the interface for it.
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..

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!
- SpaghettiCthulu 3y ago
  But why?
  - dale_glass 3y ago
    Because security is a serious problem that needs to be treated seriously for it to be useful. You can't just sprinkle it on an existing system like fairy dust, it has to be built into the design to be effective, and it needs to be periodically re-thought mercilessly. PGP for instance encourages some terrible habits, like awfully long lived keys. You have somebody signing packages with an ancient DSA-1024 key, perhaps because "SQUEE Philip Zimmermann himself signed that key back in 1996 and I can't part with it". That's not the right attitude to security. Good security requires a solution fit to whatever specific thing you need to secure, a system designed with it in mind, and a lack of sentimentality and backwards compatibility.
    - SpaghettiCthulu 3y ago
      I completely agree with your points but you seem to be missing the point which is: why does OpenPGP's versatility make it a bad candidate?
      - morelisp 3y ago
        It is not versatile - multi-purpose - it is weak - general-purpose. "Encrypt/sign these bytes with this cipher, these parameters, and this key" is the least common denominator of cryptographic ability and ignores all the work to build an actual useful cryptographic system around it. On top of this, its specific interfaces for doing that suck, so you can't even bury it as a safe "primitive" in whatever system you're trying to build (even assuming you wanted to bring in the attack surface of a 25 year old C project). Something like libsodium is actually versatile in that it offers primitives to build a broad set of safe tools on top of. It does more by doing less.
tptacek 3y ago
In general, for each major use case of file/message encryption (messaging, backup, transport, package signing, contracts, drive/filesystem encryption, &c), there is a cryptosystem that does the job better than PGP, in part by being built out of modern components and a modern understanding of cryptography†, and in part by being designed around the actual problem and not a lossy abstraction of the problem. So it's frustrating to see PGP advocates talking about these things PGP does that Signal, or Tarsnap, or Minisign, or Certificate Transparency, or whatever don't do on their own. It's like telling a line cook that a Swiss Army Knife is a meaningful competitor to a chef's knife. Like: it doesn't matter, nobody's going to use a Swiss Army Knife on the line, it's not a threat or anything, but it's so obviously wrong. † People tend to forget how underdeveloped our understanding of cryptography engineering was when PGP/GPG first came about; for a crash course, check out the IETF archives of Rogaway pleading with the IPSEC people to avoid chained CBC IVs.
- forgotmypw17 3y ago
  I don’t understand how having multiple tools, each one needing audits and effort and time to make secure, each one needing porting to all the platforms that people use, each one breaking compatibility with legacy platforms and hardware, is better than an existing tool without any of these drawbacks.
  - donaldstufft 3y ago
    Because the existing tool does a bad job at all of them, and those tools do reasonably good jobs at each of their respective tasks. Fundamentally the things you want from a secure crypto system differ depending on the context in which you're applying it. Email needs different things than package signing does than file encryption does. It's silly to pretend that the same tool can provide a good and secure experience for all of them.
    - forgotmypw17 3y ago
      I don’t think it’s that silly, and I don’t think email is that different from packages is that different from files. They’re all data with some attributes, and pgp handles them nicely, if you can write the interface for it.

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..