10 ms·

The PGP Problem: A Critique (2020)

85 points by JoachimS 5y ago

anotherhue 5y ago
I wonder how many of the criticisms would exist in a world where PGP moved to its own channel, and stopped riding on email.
- Jon_Lowtek 5y ago
  you are conflating PGP with PGP/MIME. The later is using PGP to encrypt mail. You can encrypt other things with PGP as well. But i kind of agree with your point: a lot of the "original rant" the article answers to seems to be about its author preferring to use different tools over PGP, one of the relevant use case comparisons being communication where they put Signal vs PGP/MIME. Such a rant would not exist if PGP/MIME would not be a thing. There are other use cases mentioned in the rant, but this one seems to be the primary one. However its not that "pgp rides on email" it is that "email encryption rides on pgp". Yes, for the use case of communication email encryption has pitfalls that encrypted instant messengers like signal do not have, and at the moment the later is the better choice. But Signal has other pitfalls, like piggybacking on phone numbers or its saas architecture with a single commercially controlled point of failure. Email is so damn robust, we could not kill it even if we wanted to. I honestly do not get this whole "don't sign or encrypt email - use another app" idea. We live in a world where banks send five digit one time pins using unencrypted SMS and where Microsoft signs their security newsletter with PGP. The "if i don't see the need it should not exist" approach is egocentric, arrogant and naive. E-Mail exists, and it isn't going away anytime soon, so a cryptosystem for email is a necessity.
  - tialaramex 5y ago
    Some of the "answers" are good rhetoric but bad technique. If you want to be reassured that the original rant is wrong, they're successful, and this is a prize-worthy debating tactic, but it's not useful for getting to the facts. The "answers" around MDC in particular suffer from this, they harp about how it is mentioned several times (it's a fatal problem, I think I'd mention it more than once) and you might get the impression that this means it's an invalid criticism, but notice that they carefully don't ever say so, because of course it is a fatal problem in the real world. If you dig further into the site their apology for MDC basically goes like this: If PGP had AE instead, we'd have the exact same UX and so it doesn't fix anything. Thus the problem is bad client software (weird, all the PGP software is bad, that doesn't seem like a coincidence). In fact the whole point of AEAD is that you can't build that UX. The problem is that the existing MDC handling gives back bogus plaintext and then just casually says "Also, the MDC was invalid" as if that wasn't the headline news. It behaves this way partly because MDC is optional, but also because PGP's developers don't understand that wrong is worse than failed. AE APIs just will not give you any plaintext at all when authentication fails, there is no authenticated plaintext. The result is that in PGP you can alter Bob's message "Police on high alert, act casual, wait for my next message" to read "Bring the whole shipment to the park at midnight tonight" and yes, the MDC fails and maybe Alice's client tells her there was a problem, but the message "Bring the whole shipment to the park at midnight" is still right there for Alice to act on anyway, and so guess what Alice is going to do...
    - Jon_Lowtek 5y ago
      Your example seems overly dramatic to the point of being completely unbelievable. Can you provide some reference links or other further reading? How does an attacker change the complete text in a meaningful without knowing Bobs private key?
      - tialaramex 5y ago
        Essentially, all modern symmetric encryption works by XORing something an attacker can't know with the plaintext to form a ciphertext. The recipient does the reverse operation to turn ciphertext back into plaintext. So it's actually very simple to change what it says, without knowing the key, if you know what it says now. For example, XOR the old known message with your replacement to get a stream A, then you XOR the current ciphertext with A to get a new ciphertext, which will be decrypted to give your replacement message. [Edited: I re-read this and I've oversold it substantially. In practice you won't have this easy a time with a non-toy system. But some of the cipher modes PGP still routinely uses will make it almost this easy if the attacker knows what they're doing and has the entire message text] What a modern system does here is it uses an "Authenticated Encryption" mode where the ciphertext is slightly larger such that decrypting also ends up calculating a "tag" value that should match one carried in the message. If the message was altered that tag won't match, and crucially there just is no plaintext in this case. If you have a halfway modern web browser, the secured connection to Hacker News does exactly this, so an on-path attacker can't change anything going back and forth, the most they can do is blow up your connection. But nobody was doing that when PGP was originally invented. So at first what PGP does is it relies on digital signatures over the entire message. After processing the entire message apparently from Bob, PGP sees that it has a signature, and this signature fails - this isn't the message Bob signed. Bad guys (who know the message but not the keys) can't prevent that. But it turns out that in practice they needn't care. The (bogus) decrypted plaintext is shown to Alice first, and Alice will have likely seen messages with "failed" signatures before, and she knows it's probably some stupid mail server configuration issue or something else unimportant. This message from Bob decrypted as expected, so what's the problem? Now you know what the problem is, I explained it above, but Alice almost certainly doesn't, as you didn't when you replied. It seems crazy that an "encrypted" message could be altered so easily, who would design it that way? More modern versions of (Open)PGP introduce this thing called MDC, which makes it at least possible to think about whether this tampering has happened to the raw encryption, without signatures, however for ages the default behaviour was still to just warn the user that there's a problem after showing them the bogus plaintext. In current versions this isn't what will happen with raw GnuPG itself out of the box, except there are still lots of caveats (e.g. Unix pipes defeat this) and so in practical use you often end up back with the user being shown the bogus plaintext anyway.
  - anotherhue 5y ago
    Firstly, thanks for your detailed reply. > However its not that "pgp rides on email" it is that "email encryption rides on pgp" Doesn't it go both ways though? The web-of-trust seems email focused, keyservers seem email focused. 'gpg --gen-key' straight up asks you to encode your email into the metadata. I guess bootstrapping on an existing network is always a pain point. What I was trying to highlight were the issues faced by 'partial adoption' of encryption, namely: A) It being cumbersome in the MUA and therefore likely to be ignored/disabled/complained about B) The myriad of ways for an OPSEC failure, or in common parlance, clicking the wrong button. If PGPMAIL or somesuch had eclipsed plain-old email, as Signal/WhatsApp have eclipsed SMS, then these issues could be resolved at the platform level.
- _wldu 5y ago
  I use PGP outside of email all the time (you should too). You can PGP encrypt sensitive files (passwords, finances, etc.) to your PGP key and the PGP keys of your family members and upload them to shared Google and MS O365 folders. For important, sensitive data that you need to access and keep confidential, PGP is great. Nothing else really comes close (despite all the criticisms).
  - sodality2 5y ago
    Age would be better for that: https://github.com/FiloSottile/age https://github.com/FiloSottile/age
    - upofadown 5y ago
      There is a comparison of age to OpenPGP on the same site: * https://articles.59.ca/doku.php?id=pgpfan:agevspgp https://articles.59.ca/doku.php?id=pgpfan:agevspgp
      - matbatt38 5y ago
        This page basically says that PGP is better in most use cases
  - zaphar 5y ago
    Meh, I would rather use age[0] 0: https://github.com/FiloSottile/age https://github.com/FiloSottile/age
    - waynesonfire 5y ago
      Meh.
brabel 5y ago
I had to deep dive into the details of PGP in order to setup a trusted chain of artifacts in our internal CI system, all the way to published artifacts on Maven Central (the Java defacto main package repository)... it was a tough ride, as PGP is not very simple for end users, even with all the tooing they've created. The GNU PGP utility[1] is pretty easy to use on the terminal, and the UI version[2] actually makes it even easier to sign/encrypt/verify stuff and manage your local keys (also to integrate with email clients, which seems to be the most common use of PGP)... The problem is just that understanding exactly what a key is for, why I need a sub-key, how to move keys between CI agents securely, how to rotate keys, when to use a keyserver, where to store my master key, how to trust someone else's keys (or sub-keys?!) and so on... is really difficult and there's no one simple answer. Howver, I'm afraid these problems are independent of PGP itself: you'll have these problems whatever system you use, as the "key" (pun intended) issue is not the technology you use, but the public-key intfrastructure problem[3]. In summary: how do you trust someone else's public key without phisically having access to it directly from them? If you get the key online, wow can you know that the source is definitely reliable and the channel of communication has not been compromised? On the Web, Certificate Authorities (CA) play the role of vouching for someone's keys through certificate signing. But this is not an appropriate model for things like personal keys, and it introduces its own issues as well[4]. In PGP, the solution seems to be Key Signing Parties[5]! Sounds fun, but also completely unfeasible on the scale of the web. I don't know how Signal and other new solutions fair compared to PGP on these problems, but would be happy to know if anyone has any advice. [1] https://gnupg.org/ https://gnupg.org/ [2] https://gpgtools.org/ https://gpgtools.org/ [3] https://en.wikipedia.org/wiki/Public_key_infrastructure https://en.wikipedia.org/wiki/Public_key_infrastructure [4] https://gemini.circumlunar.space/docs/tls-tutorial.gmi https://gemini.circumlunar.space/docs/tls-tutorial.gmi [5] https://en.wikipedia.org/wiki/Key_signing_party https://en.wikipedia.org/wiki/Key_signing_party
- georgyo 5y ago
  I am a huge fan of OpenPGP, but the Web of Trust is never going mainstream. However, I do think things like OpenPGP-CA are going to make things _a lot_ easier for everyone. And I really hope that it catches on: https://openpgp-ca.org/blog/openpgp_ca_0_10_1/ https://openpgp-ca.org/blog/openpgp_ca_0_10_1/
mxxc 5y ago
i think the main problem with PGP has to do with its general usability, and often wrappers, GUIs etc. are mere workarounds to its UX flaws. like the article says, it's not much more than a swiss army knife and for many of the uses that most people mention here there are often better tools – end-to-end secure messaging, file encryption and so on. i think pgp is a reasonable tool in absolute zero-trust circumstances, where one has to send and receive messages and files through channels that are at constant risk of tapping or phishing. even there, i'd say it's "very annoying to use" but it's probably better than death, or jail.
______- 5y ago
The ergonomics of PGP are awful. The author's appreciation of Signal is valid, except for one caveat: what if your phone has malware? That's all your fancy Signal crypto out the window. It's the usual argument of: `A chain is only as strong as its weakest link`. My point is: there are other factors to consider besides advice like: `Just download Signal and you're golden`. Edit: I'm referring to people casually saying: `Download Signal and you'll be fine` and not pointing out other OPSEC practices we all need to follow, regardless of threat model. (Not clicking on malicious links sent via SMS etc).
- brians 5y ago
  Can you describe a system that is effective when your phone has malware? I have a little experience with this, designing systems that use TPMs and remote attestation to shut down communication rather than allow forgery or leaks. It’s very delicate to begin with, even if one entity owns all the devices, and unsolved for the general case. But iOS and ChromeOS seem pretty good.
  - ______- 5y ago
    > Can you describe a system that is effective when your phone has malware? I'm referring to people casually saying: `Download Signal and you'll be fine` and not pointing out other OPSEC practices we all need to follow, regardless of threat model. (Not clicking on malicious links sent via SMS etc).
    - pvg 5y ago
      other OPSEC practices we all need to follow, regardless of threat model. That doesn't really add up - a goals of things like more secure phones and secure general purpose messengers is explicitly to provide a high level of security without following a bunch of OPSEC practices. You aren't going to get mass adoption of more secure systems by insisting everyone take up OPSEC practices 'regardless of threat model'. The aim is to reach that adoption through systems that offer a lot of security without a lot of security-related ceremony. It's sort of inherent in the notion of mass adoption.
  - 5y ago
cedilla 5y ago
This critique doesn't really convince me. It mostly says that the original article is wrong, but is mostly silent on why. But the claim that forward secrecy is unnecessary because STARTTLS protects mail in transist is downright odd. First, it seems self-defeating: if STARTTLS protects me from adverseries, why use PGP? But of course, it doesn't. I can't know if my mail is protected by STARTTLS in advance, and I can't know if one of the mail providers involved is cooperating with the government. Especially someone who fears being targeted by a state-level actor should assume that every mail provider is compromised. Really, that is the reason to encrypt mails in the first place, so when someone criticizes PGP's effectiveness for that purpose you really can't fall back to trusting mail providers.
- dale_glass 5y ago
  STARTTLS is of little help. It's client to server encryption. If say, alice@ispa.com emails bob@ispb.ru, then the transit between Alice's computer and IspA, IspA and IspB, and IspB and Bob is protected. But only during transit. Both IspA and IspB get a completely cleartext email in their servers, where there well could be monitoring equipment or software installed. If you're concerned about a family member watching the traffic going through your router, this fixes your problem. But if you're concerned about governments, it absolutely does not, because they can easily convince an ISP to install interception infrastructure inside their datacenter, where the mail is in clear text. PGP on the other hand is end-to-end, Alice to Bob, and the data doesn't exist as cleartext anywhere else.
  - jcranmer 5y ago
    There are two things you're missing here. The first, and more minor one, is that effective deployment of keys for encryption/signing tends to require cooperation of the email provider anyways, giving them the ability to report trusted keys for your identity that they can use to MITM you. Indeed, a few of the suggestions for key distribution contained in threads on this post have exactly this flaw (I leave it an exercise to the reader to find which ones). More importantly, even PGP doesn't fully protect information: the headers are still sent in full plaintext. This means that your email provider still knows whom you talked to, when you did so, and the subject of your message. I suspect that most of the government's interest in your personal email isn't in the contents of the email, but precisely this metadata that PGP makes no effort to hide whatsoever. If you're a dissident in Venezuela who's worried about the government finding out you're talking to foreign reporters... well, PGP won't help you. This ends up being the conundrum of "secure" email: it's sufficient for the job (assuming that the UX is more well-thought out than it often is) only if you want to hide what you're saying but not whom you're saying it to. And that is not sufficient for what most people who want secure messaging desire.
kyrra 5y ago
The discussion of the original article (The PGP Problem) got a lot of comments on HN 2 years ago: https://news.ycombinator.com/item?id=20455780 https://news.ycombinator.com/item?id=20455780 (googler, opinions are my own) Over at payments in Google, we still use PGP for communicating with the financial world (JWE supported too)[0]. The one advantage of PGP is that it's been around so long, many companies already have it set up in their systems when communicating with them. Be it files or application level communications, support is already there. PGP definitely has it's rough edges. Tools with simplified APIs like Tink[1] seems to be the way security researches want to go, as PGP definitely makes it easy to do things wrong (just due to how much legacy support it has out there). [0] https://developers.google.com/standard-payments/guides/connectivity/security/application-layer https://developers.google.com/standard-payments/guides/conne... [1] https://github.com/google/tink https://github.com/google/tink
- themulticaster 5y ago
  I'm curious about the communication with the financial world you mention. Could you elaborate what kind of interface or API you're talking about, or at least which area of finance is involved?
  - kyrra 5y ago
    I really should say payments world. Banks use PGP regularly for file transfer (bank statements and the like). Payment processors use PGP for settlement statement transferring. The page I linked uses PGP for application layer encryption. If you poke around the reference page[0], you see a bunch of different specs that 3rd party platforms can build against and be hooked up into Google as a form-of-payment (ie: used by people to pay for Ads, Play, Cloud, etc...). We encrypt each message passed between Google and a payment process with PGP. These are just normal server-to-server calls over HTTPS with JSON payloads (with the json payload being PGP encrypted). [0] https://developers.google.com/standard-payments/payment-integrator-tokenized-fop-api-v1 https://developers.google.com/standard-payments/payment-inte...
tptacek 5y ago
I wrote the post this article is attempting to rebut. You may be interested in (or infuriated by) a follow-up post I wrote: https://latacora.micro.blog/2020/02/19/stop-using-encrypted.html https://latacora.micro.blog/2020/02/19/stop-using-encrypted.... I think this critique is pretty funny, in that it tends to confirm my complaints about PGP while pretending it's doing something else. A particular favorite part for me is when they point out that their local PGP installation doesn't include CAST5 --- but does include 3DES, the canonical insecure 64-bit-block cipher. I would generally caution people against taking cryptographic advice from people who write things like "the author does not understand why authenticated encryption is not used or even required for the things that PGP is normally used for." As a general (and often surprising) rule, it tends to turn out that you need authenticity in order to even obtain confidentiality. There's a whole "doom principle" about this.
- dane-pgp 5y ago
  There are some good points in there, and, while I don't want to provide a definitive rebuttal, I think it is worth mentioning how close PGP is to something that can be recommended. Let me respond to the issues one by one: > If messages can be sent in plaintext, they will be sent in plaintext. This is actually perhaps the strongest argument. If I'm steelmanning it correctly, it says that any system which tries to be backwards compatible with an insecure protocol is likely to result in some messages being unencrypted when they're not supposed to, either by accident, or due to an attack. It's true that by introducing an entirely new, backwards incompatible protocol, this entire class of problems can be almost eliminated. There is still, of course, the problem that someone copy-pastes text from a secure context to an insecure context, but I agree that there is a meaningful reduction of risk being offered here. However, it is worth comparing this situation to the web ecosystem. The fact is, browsers still support both HTTP and HTTPS, and a lot of work has been done on protocols, and implementations, and UX to stop downgrade attacks from happening. To avoid this problem, we could have defined HTTP to be the legacy web, and come up with an entirely new protocol (perhaps one where a benevolent dictator provides the only accepted client and server implementations), but I'm glad we didn't go down that route. > Metadata is as important as content, and email leaks it. While the most popular email encryption tool doesn't encrypt subject lines, Delta Chat, for example[0], does. That's therefore not an argument against encrypted email as it against using clients that aren't as good as Delta Chat. However, your point about backwards compatibility is still relevant here. I suppose the analogous scenario is that with HTTPS we know whether the connection to the server is encrypted by looking at the URL (or the padlock, or other clues that users don't really follow). However, until quite recently there was still the issue that a request over HTTPS could pull in sub-resources that weren't encrypted, which feels somewhat equivalent to someone accessing their Delta Chat inbox in a separate client that doesn't use PGP. As for other metadata, it would be possible for email providers to implement a type of anonymous remailer, where the sending server hides the sender address, and the recipient server decrypts an outer layer of encryption to find the intended recipient, but I admit that no providers currently offer such a service. If it were implemented, though, I think it could offer better security than centralised services, because the metadata could be split across different jurisdictions, removing the single point of failure. > Every archived message will eventually leak. This seems to be an argument that if you store sensitive documents on your computer, then the security of those documents is only as good as your at-rest encryption (and your ability to stop someone separating you from your computer when it is unlocked). You accept that recipients can configure their email clients to delete old messages stored on their computer, but then you seem to require that senders can delete their old messages on other people's computers, which doesn't seem like something any protocol can enforce. (You also make a point here about how JavaScript sent from a server can't be made secure, because a server can send a different script next time you visit. That's true, unless the initial page of the web app is stored as a bookmarklet[1], or secured by a hashlink[2], which browsers currently don't support). > Every long term secret will eventually leak. Yes, it would be nice to have Perfect Forward Secrecy supported by PGP encrypted email. There has at least been some effort to advance that at the IETF in the past[3], and it's also being considered as part of the future development of Autocrypt.[4] [0] https://delta.chat/pt/help#how-does-delta-chat-protect-my-metadata https://delta.chat/pt/help#how-does-delta-chat-protect-my-me... [1] https://news.ycombinator.com/item?id=17776456 https://news.ycombinator.com/item?id=17776456 [2] https://datatracker.ietf.org/doc/draft-sporny-hashlink/ https://datatracker.ietf.org/doc/draft-sporny-hashlink/ [3] https://datatracker.ietf.org/doc/html/draft-brown-pgp-pfs-03 https://datatracker.ietf.org/doc/html/draft-brown-pgp-pfs-03 [4] https://autocrypt.org/next-steps.html#deletable-forward-secure-encrypted-mail https://autocrypt.org/next-steps.html#deletable-forward-secu...
ch33zer 5y ago
I tried to set up PGP on a yubikey and use that for SSH encryption, email signing, and other things. In the end PGP made is so uncomfortable that I just stopped. PGP may be a secure piece of software (I don't know enough about this to have an opinion), but it's not a usable piece of software.

85 points by JoachimS 5y ago

I wonder how many of the criticisms would exist in a world where PGP moved to its own channel, and stopped riding on email.

Jon_Lowtek 5y ago
you are conflating PGP with PGP/MIME. The later is using PGP to encrypt mail. You can encrypt other things with PGP as well. But i kind of agree with your point: a lot of the "original rant" the article answers to seems to be about its author preferring to use different tools over PGP, one of the relevant use case comparisons being communication where they put Signal vs PGP/MIME. Such a rant would not exist if PGP/MIME would not be a thing. There are other use cases mentioned in the rant, but this one seems to be the primary one. However its not that "pgp rides on email" it is that "email encryption rides on pgp". Yes, for the use case of communication email encryption has pitfalls that encrypted instant messengers like signal do not have, and at the moment the later is the better choice. But Signal has other pitfalls, like piggybacking on phone numbers or its saas architecture with a single commercially controlled point of failure. Email is so damn robust, we could not kill it even if we wanted to. I honestly do not get this whole "don't sign or encrypt email - use another app" idea. We live in a world where banks send five digit one time pins using unencrypted SMS and where Microsoft signs their security newsletter with PGP. The "if i don't see the need it should not exist" approach is egocentric, arrogant and naive. E-Mail exists, and it isn't going away anytime soon, so a cryptosystem for email is a necessity.
- tialaramex 5y ago
  Some of the "answers" are good rhetoric but bad technique. If you want to be reassured that the original rant is wrong, they're successful, and this is a prize-worthy debating tactic, but it's not useful for getting to the facts. The "answers" around MDC in particular suffer from this, they harp about how it is mentioned several times (it's a fatal problem, I think I'd mention it more than once) and you might get the impression that this means it's an invalid criticism, but notice that they carefully don't ever say so, because of course it is a fatal problem in the real world. If you dig further into the site their apology for MDC basically goes like this: If PGP had AE instead, we'd have the exact same UX and so it doesn't fix anything. Thus the problem is bad client software (weird, all the PGP software is bad, that doesn't seem like a coincidence). In fact the whole point of AEAD is that you can't build that UX. The problem is that the existing MDC handling gives back bogus plaintext and then just casually says "Also, the MDC was invalid" as if that wasn't the headline news. It behaves this way partly because MDC is optional, but also because PGP's developers don't understand that wrong is worse than failed. AE APIs just will not give you any plaintext at all when authentication fails, there is no authenticated plaintext. The result is that in PGP you can alter Bob's message "Police on high alert, act casual, wait for my next message" to read "Bring the whole shipment to the park at midnight tonight" and yes, the MDC fails and maybe Alice's client tells her there was a problem, but the message "Bring the whole shipment to the park at midnight" is still right there for Alice to act on anyway, and so guess what Alice is going to do...
  - Jon_Lowtek 5y ago
    Your example seems overly dramatic to the point of being completely unbelievable. Can you provide some reference links or other further reading? How does an attacker change the complete text in a meaningful without knowing Bobs private key?
    - tialaramex 5y ago
      Essentially, all modern symmetric encryption works by XORing something an attacker can't know with the plaintext to form a ciphertext. The recipient does the reverse operation to turn ciphertext back into plaintext. So it's actually very simple to change what it says, without knowing the key, if you know what it says now. For example, XOR the old known message with your replacement to get a stream A, then you XOR the current ciphertext with A to get a new ciphertext, which will be decrypted to give your replacement message. [Edited: I re-read this and I've oversold it substantially. In practice you won't have this easy a time with a non-toy system. But some of the cipher modes PGP still routinely uses will make it almost this easy if the attacker knows what they're doing and has the entire message text] What a modern system does here is it uses an "Authenticated Encryption" mode where the ciphertext is slightly larger such that decrypting also ends up calculating a "tag" value that should match one carried in the message. If the message was altered that tag won't match, and crucially there just is no plaintext in this case. If you have a halfway modern web browser, the secured connection to Hacker News does exactly this, so an on-path attacker can't change anything going back and forth, the most they can do is blow up your connection. But nobody was doing that when PGP was originally invented. So at first what PGP does is it relies on digital signatures over the entire message. After processing the entire message apparently from Bob, PGP sees that it has a signature, and this signature fails - this isn't the message Bob signed. Bad guys (who know the message but not the keys) can't prevent that. But it turns out that in practice they needn't care. The (bogus) decrypted plaintext is shown to Alice first, and Alice will have likely seen messages with "failed" signatures before, and she knows it's probably some stupid mail server configuration issue or something else unimportant. This message from Bob decrypted as expected, so what's the problem? Now you know what the problem is, I explained it above, but Alice almost certainly doesn't, as you didn't when you replied. It seems crazy that an "encrypted" message could be altered so easily, who would design it that way? More modern versions of (Open)PGP introduce this thing called MDC, which makes it at least possible to think about whether this tampering has happened to the raw encryption, without signatures, however for ages the default behaviour was still to just warn the user that there's a problem after showing them the bogus plaintext. In current versions this isn't what will happen with raw GnuPG itself out of the box, except there are still lots of caveats (e.g. Unix pipes defeat this) and so in practical use you often end up back with the user being shown the bogus plaintext anyway.
- anotherhue 5y ago
  Firstly, thanks for your detailed reply. > However its not that "pgp rides on email" it is that "email encryption rides on pgp" Doesn't it go both ways though? The web-of-trust seems email focused, keyservers seem email focused. 'gpg --gen-key' straight up asks you to encode your email into the metadata. I guess bootstrapping on an existing network is always a pain point. What I was trying to highlight were the issues faced by 'partial adoption' of encryption, namely: A) It being cumbersome in the MUA and therefore likely to be ignored/disabled/complained about B) The myriad of ways for an OPSEC failure, or in common parlance, clicking the wrong button. If PGPMAIL or somesuch had eclipsed plain-old email, as Signal/WhatsApp have eclipsed SMS, then these issues could be resolved at the platform level.
_wldu 5y ago
I use PGP outside of email all the time (you should too). You can PGP encrypt sensitive files (passwords, finances, etc.) to your PGP key and the PGP keys of your family members and upload them to shared Google and MS O365 folders. For important, sensitive data that you need to access and keep confidential, PGP is great. Nothing else really comes close (despite all the criticisms).
- sodality2 5y ago
  Age would be better for that: https://github.com/FiloSottile/age https://github.com/FiloSottile/age
  - upofadown 5y ago
    There is a comparison of age to OpenPGP on the same site: * https://articles.59.ca/doku.php?id=pgpfan:agevspgp https://articles.59.ca/doku.php?id=pgpfan:agevspgp
    - matbatt38 5y ago
      This page basically says that PGP is better in most use cases
- zaphar 5y ago
  Meh, I would rather use age[0] 0: https://github.com/FiloSottile/age https://github.com/FiloSottile/age
  - waynesonfire 5y ago
    Meh.

brabel 5y ago

I had to deep dive into the details of PGP in order to setup a trusted chain of artifacts in our internal CI system, all the way to published artifacts on Maven Central (the Java defacto main package repository)... it was a tough ride, as PGP is not very simple for end users, even with all the tooing they've created. The GNU PGP utility[1] is pretty easy to use on the terminal, and the UI version[2] actually makes it even easier to sign/encrypt/verify stuff and manage your local keys (also to integrate with email clients, which seems to be the most common use of PGP)... The problem is just that understanding exactly what a key is for, why I need a sub-key, how to move keys between CI agents securely, how to rotate keys, when to use a keyserver, where to store my master key, how to trust someone else's keys (or sub-keys?!) and so on... is really difficult and there's no one simple answer. Howver, I'm afraid these problems are independent of PGP itself: you'll have these problems whatever system you use, as the "key" (pun intended) issue is not the technology you use, but the public-key intfrastructure problem[3]. In summary: how do you trust someone else's public key without phisically having access to it directly from them? If you get the key online, wow can you know that the source is definitely reliable and the channel of communication has not been compromised? On the Web, Certificate Authorities (CA) play the role of vouching for someone's keys through certificate signing. But this is not an appropriate model for things like personal keys, and it introduces its own issues as well[4]. In PGP, the solution seems to be Key Signing Parties[5]! Sounds fun, but also completely unfeasible on the scale of the web. I don't know how Signal and other new solutions fair compared to PGP on these problems, but would be happy to know if anyone has any advice. [1] https://gnupg.org/ https://gnupg.org/ [2] https://gpgtools.org/ https://gpgtools.org/ [3] https://en.wikipedia.org/wiki/Public_key_infrastructure https://en.wikipedia.org/wiki/Public_key_infrastructure [4] https://gemini.circumlunar.space/docs/tls-tutorial.gmi https://gemini.circumlunar.space/docs/tls-tutorial.gmi [5] https://en.wikipedia.org/wiki/Key_signing_party https://en.wikipedia.org/wiki/Key_signing_party

georgyo 5y ago
I am a huge fan of OpenPGP, but the Web of Trust is never going mainstream. However, I do think things like OpenPGP-CA are going to make things _a lot_ easier for everyone. And I really hope that it catches on: https://openpgp-ca.org/blog/openpgp_ca_0_10_1/ https://openpgp-ca.org/blog/openpgp_ca_0_10_1/

mxxc 5y ago

i think the main problem with PGP has to do with its general usability, and often wrappers, GUIs etc. are mere workarounds to its UX flaws. like the article says, it's not much more than a swiss army knife and for many of the uses that most people mention here there are often better tools – end-to-end secure messaging, file encryption and so on. i think pgp is a reasonable tool in absolute zero-trust circumstances, where one has to send and receive messages and files through channels that are at constant risk of tapping or phishing. even there, i'd say it's "very annoying to use" but it's probably better than death, or jail.

______- 5y ago

The ergonomics of PGP are awful. The author's appreciation of Signal is valid, except for one caveat: what if your phone has malware? That's all your fancy Signal crypto out the window. It's the usual argument of: `A chain is only as strong as its weakest link`. My point is: there are other factors to consider besides advice like: `Just download Signal and you're golden`. Edit: I'm referring to people casually saying: `Download Signal and you'll be fine` and not pointing out other OPSEC practices we all need to follow, regardless of threat model. (Not clicking on malicious links sent via SMS etc).

brians 5y ago
Can you describe a system that is effective when your phone has malware? I have a little experience with this, designing systems that use TPMs and remote attestation to shut down communication rather than allow forgery or leaks. It’s very delicate to begin with, even if one entity owns all the devices, and unsolved for the general case. But iOS and ChromeOS seem pretty good.
- ______- 5y ago
  > Can you describe a system that is effective when your phone has malware? I'm referring to people casually saying: `Download Signal and you'll be fine` and not pointing out other OPSEC practices we all need to follow, regardless of threat model. (Not clicking on malicious links sent via SMS etc).
  - pvg 5y ago
    other OPSEC practices we all need to follow, regardless of threat model. That doesn't really add up - a goals of things like more secure phones and secure general purpose messengers is explicitly to provide a high level of security without following a bunch of OPSEC practices. You aren't going to get mass adoption of more secure systems by insisting everyone take up OPSEC practices 'regardless of threat model'. The aim is to reach that adoption through systems that offer a lot of security without a lot of security-related ceremony. It's sort of inherent in the notion of mass adoption.
- 5y ago

cedilla 5y ago

This critique doesn't really convince me. It mostly says that the original article is wrong, but is mostly silent on why. But the claim that forward secrecy is unnecessary because STARTTLS protects mail in transist is downright odd. First, it seems self-defeating: if STARTTLS protects me from adverseries, why use PGP? But of course, it doesn't. I can't know if my mail is protected by STARTTLS in advance, and I can't know if one of the mail providers involved is cooperating with the government. Especially someone who fears being targeted by a state-level actor should assume that every mail provider is compromised. Really, that is the reason to encrypt mails in the first place, so when someone criticizes PGP's effectiveness for that purpose you really can't fall back to trusting mail providers.

dale_glass 5y ago
STARTTLS is of little help. It's client to server encryption. If say, alice@ispa.com emails bob@ispb.ru, then the transit between Alice's computer and IspA, IspA and IspB, and IspB and Bob is protected. But only during transit. Both IspA and IspB get a completely cleartext email in their servers, where there well could be monitoring equipment or software installed. If you're concerned about a family member watching the traffic going through your router, this fixes your problem. But if you're concerned about governments, it absolutely does not, because they can easily convince an ISP to install interception infrastructure inside their datacenter, where the mail is in clear text. PGP on the other hand is end-to-end, Alice to Bob, and the data doesn't exist as cleartext anywhere else.
- jcranmer 5y ago
  There are two things you're missing here. The first, and more minor one, is that effective deployment of keys for encryption/signing tends to require cooperation of the email provider anyways, giving them the ability to report trusted keys for your identity that they can use to MITM you. Indeed, a few of the suggestions for key distribution contained in threads on this post have exactly this flaw (I leave it an exercise to the reader to find which ones). More importantly, even PGP doesn't fully protect information: the headers are still sent in full plaintext. This means that your email provider still knows whom you talked to, when you did so, and the subject of your message. I suspect that most of the government's interest in your personal email isn't in the contents of the email, but precisely this metadata that PGP makes no effort to hide whatsoever. If you're a dissident in Venezuela who's worried about the government finding out you're talking to foreign reporters... well, PGP won't help you. This ends up being the conundrum of "secure" email: it's sufficient for the job (assuming that the UX is more well-thought out than it often is) only if you want to hide what you're saying but not whom you're saying it to. And that is not sufficient for what most people who want secure messaging desire.

kyrra 5y ago

The discussion of the original article (The PGP Problem) got a lot of comments on HN 2 years ago: https://news.ycombinator.com/item?id=20455780 https://news.ycombinator.com/item?id=20455780 (googler, opinions are my own) Over at payments in Google, we still use PGP for communicating with the financial world (JWE supported too)[0]. The one advantage of PGP is that it's been around so long, many companies already have it set up in their systems when communicating with them. Be it files or application level communications, support is already there. PGP definitely has it's rough edges. Tools with simplified APIs like Tink[1] seems to be the way security researches want to go, as PGP definitely makes it easy to do things wrong (just due to how much legacy support it has out there). [0] https://developers.google.com/standard-payments/guides/connectivity/security/application-layer https://developers.google.com/standard-payments/guides/conne... [1] https://github.com/google/tink https://github.com/google/tink

themulticaster 5y ago
I'm curious about the communication with the financial world you mention. Could you elaborate what kind of interface or API you're talking about, or at least which area of finance is involved?
- kyrra 5y ago
  I really should say payments world. Banks use PGP regularly for file transfer (bank statements and the like). Payment processors use PGP for settlement statement transferring. The page I linked uses PGP for application layer encryption. If you poke around the reference page[0], you see a bunch of different specs that 3rd party platforms can build against and be hooked up into Google as a form-of-payment (ie: used by people to pay for Ads, Play, Cloud, etc...). We encrypt each message passed between Google and a payment process with PGP. These are just normal server-to-server calls over HTTPS with JSON payloads (with the json payload being PGP encrypted). [0] https://developers.google.com/standard-payments/payment-integrator-tokenized-fop-api-v1 https://developers.google.com/standard-payments/payment-inte...

tptacek 5y ago

I wrote the post this article is attempting to rebut. You may be interested in (or infuriated by) a follow-up post I wrote: https://latacora.micro.blog/2020/02/19/stop-using-encrypted.html https://latacora.micro.blog/2020/02/19/stop-using-encrypted.... I think this critique is pretty funny, in that it tends to confirm my complaints about PGP while pretending it's doing something else. A particular favorite part for me is when they point out that their local PGP installation doesn't include CAST5 --- but does include 3DES, the canonical insecure 64-bit-block cipher. I would generally caution people against taking cryptographic advice from people who write things like "the author does not understand why authenticated encryption is not used or even required for the things that PGP is normally used for." As a general (and often surprising) rule, it tends to turn out that you need authenticity in order to even obtain confidentiality. There's a whole "doom principle" about this.

dane-pgp 5y ago
There are some good points in there, and, while I don't want to provide a definitive rebuttal, I think it is worth mentioning how close PGP is to something that can be recommended. Let me respond to the issues one by one: > If messages can be sent in plaintext, they will be sent in plaintext. This is actually perhaps the strongest argument. If I'm steelmanning it correctly, it says that any system which tries to be backwards compatible with an insecure protocol is likely to result in some messages being unencrypted when they're not supposed to, either by accident, or due to an attack. It's true that by introducing an entirely new, backwards incompatible protocol, this entire class of problems can be almost eliminated. There is still, of course, the problem that someone copy-pastes text from a secure context to an insecure context, but I agree that there is a meaningful reduction of risk being offered here. However, it is worth comparing this situation to the web ecosystem. The fact is, browsers still support both HTTP and HTTPS, and a lot of work has been done on protocols, and implementations, and UX to stop downgrade attacks from happening. To avoid this problem, we could have defined HTTP to be the legacy web, and come up with an entirely new protocol (perhaps one where a benevolent dictator provides the only accepted client and server implementations), but I'm glad we didn't go down that route. > Metadata is as important as content, and email leaks it. While the most popular email encryption tool doesn't encrypt subject lines, Delta Chat, for example[0], does. That's therefore not an argument against encrypted email as it against using clients that aren't as good as Delta Chat. However, your point about backwards compatibility is still relevant here. I suppose the analogous scenario is that with HTTPS we know whether the connection to the server is encrypted by looking at the URL (or the padlock, or other clues that users don't really follow). However, until quite recently there was still the issue that a request over HTTPS could pull in sub-resources that weren't encrypted, which feels somewhat equivalent to someone accessing their Delta Chat inbox in a separate client that doesn't use PGP. As for other metadata, it would be possible for email providers to implement a type of anonymous remailer, where the sending server hides the sender address, and the recipient server decrypts an outer layer of encryption to find the intended recipient, but I admit that no providers currently offer such a service. If it were implemented, though, I think it could offer better security than centralised services, because the metadata could be split across different jurisdictions, removing the single point of failure. > Every archived message will eventually leak. This seems to be an argument that if you store sensitive documents on your computer, then the security of those documents is only as good as your at-rest encryption (and your ability to stop someone separating you from your computer when it is unlocked). You accept that recipients can configure their email clients to delete old messages stored on their computer, but then you seem to require that senders can delete their old messages on other people's computers, which doesn't seem like something any protocol can enforce. (You also make a point here about how JavaScript sent from a server can't be made secure, because a server can send a different script next time you visit. That's true, unless the initial page of the web app is stored as a bookmarklet[1], or secured by a hashlink[2], which browsers currently don't support). > Every long term secret will eventually leak. Yes, it would be nice to have Perfect Forward Secrecy supported by PGP encrypted email. There has at least been some effort to advance that at the IETF in the past[3], and it's also being considered as part of the future development of Autocrypt.[4] [0] https://delta.chat/pt/help#how-does-delta-chat-protect-my-metadata https://delta.chat/pt/help#how-does-delta-chat-protect-my-me... [1] https://news.ycombinator.com/item?id=17776456 https://news.ycombinator.com/item?id=17776456 [2] https://datatracker.ietf.org/doc/draft-sporny-hashlink/ https://datatracker.ietf.org/doc/draft-sporny-hashlink/ [3] https://datatracker.ietf.org/doc/html/draft-brown-pgp-pfs-03 https://datatracker.ietf.org/doc/html/draft-brown-pgp-pfs-03 [4] https://autocrypt.org/next-steps.html#deletable-forward-secure-encrypted-mail https://autocrypt.org/next-steps.html#deletable-forward-secu...

ch33zer 5y ago

I tried to set up PGP on a yubikey and use that for SSH encryption, email signing, and other things. In the end PGP made is so uncomfortable that I just stopped. PGP may be a secure piece of software (I don't know enough about this to have an opinion), but it's not a usable piece of software.