Operational PGP

6 comments

I don't think you could make a better case for not attempting to securely email people than this document --- it's good! It's very well done.

I’m so sad there aren’t free certificates for emails address anymore. S/MIME is so easy to use and makes so much sense…

It makes sense if end-to-end security isn't a requirement; otherwise: it chains up to certificate authorities. From a security engineering perspective, CAs are what you use when you have constant introductions between mutually untrusted parties. That's not how email conversations work!

S/MIME is still end to end encrypted. The fact that it relies on certificates means that it doesn’t protects against spoofing and one can argue that the certificate chain makes spoofing “easier” by creating an implicit chain of trust.

However pretty much every E2EE protocol doesn’t addresses spoofing without a side channel exchange of some sort which would allow you to pin the key of the party you wish to communicate with.

My understanding is that p≡p <https://pep.software/about/> was designed to automate all the modern best practices of using e-mail with PGP.

To bad Thunderbird went with their own setup instead of gnupg :(

Can we just write off this whole endeavour already? 20 years of complication, confusion and opportunity for catastrophe.

You are far better off mailing something sensitive. Or if you must be digital, asking the recipients for a disposable age key or similar.

I know that it is fashionable to criticize PGP, but...

- I feel knowledgeable enough to use PGP correctly w.r.t. my threat model.

- Whenever someone claims that "every single use-case has a better alternative", I look at the alternative. Many (most of the?) times the alternative is just not mature enough.

So my question is the following: if PGP is so complicated and confusing, and alternatives are so much better, why is it that so many people keep using PGP?

Give me viable alternatives, and I will use them. But as long as PGP is the most convenient (yes, I mean convenient) I find, I will use PGP.

We have more choices than store and forward now. Look at systems like Croc or magic wormhole to exchange files. Look at systems like the axolotl prekey ratchet if you definitely need async connectivity.

The actual use cases for PGP are few and far between. Signing public releases, and attempting to send unsolicited secure mail to someone you don't know.

Minisign and Sigstore are two purpose-build cryptosystems for proving the authenticity of public software releases.

What's your threat model? What are threat models you would not be comfortable trusting to properly-operationalized PGP?

To be fair, "properly operationalised" anything is probably secure, or sensibly degrades when the axioms are up.

I think the question is, "what is the cost of properly operationalising" it. TFA mentions frequent manual rekeying as a poor man's PFS. Life is too short for that.

(I knew this discussion would summon you like a ghost of crypto past).

Right, but I'm trying to ask a more interesting question. What are actual real-world security problems where you're comfortable using PGP, and what are some problems where that's not enough for you? As someone else on the thread alluded to: what's missing from a lot of discussion of PGP is "what are you using it for". "Secure email" can't be the answer; what exactly are you emailing?

Answering that on HN is the final operational security failure listed in the article.

When set up it works like a charm, I would say better than TLS. If you work at a place with a rigid IT department it sucks.

Putting aside all the crypto complications, the number one thing a user needs to know is not to ever put something sensitive in the subject field.

You know, that huge box that is literally the second field your email client presents to you. The dissonance is catastrophic.

As far as I can tell the number one real world use case for PGP mail is computer people cosplaying as spooks.

It is the user interface that is insecure, and there's no fixing that.

I actually think the Subject header is only the third-worst thing about attempting to secure email; the first is that there's no mechanism in SMTP to force encryption (everybody who has ever done a long-term encrypted email system has seen this happen; in fact, if someone told me they hadn't seen an accidentally-unencrypted reply, it would be a "tell" to me that they'd never seriously used encrypted email), and my second concern would be that everyone's email applications include "search", implying archives of plaintext email.

In fourth place: from a theory perspective, PGP's keying/identity system guarantees eventual compromise, which is why no modern messaging system works that way.

[deleted]