Operational PGP (2015) | Hacker News Reader

Operational PGP (2015)

gist.github.com

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

Maybe there is actually; I’ll try that. https://github.com/polhenarejos/acme_email

EDIT: Mostly useless; have to trust a root CA (CASTLE).

Actalis does do free S/MIME certificates for private use, but they do not allow using your own CSR. They generate the private key for you and allow you to download it, but the key stays on the server forever AFAICT.

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.

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.

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.

How much can I trust Minisign and Sigstore? I mean PGP is everywhere, everybody knows what it is and it has been maintained for decades.

If I sign a file with Minisign, how likely is it that the person who will want to check the signature will know what Minisign is, will be on a system that has a trustworthy implementation of it, and how likely is it that this implementation will be maintained for at least some years? And does Minisign work with hardware keys?

I looked at the Sigstore website, and to be very honest I don't really understand what it does. They seem to have a tool for signing containers (not my use-case) and other things I don't think I do. Do they have a tool to sign a file? Then should I use Minisign or Sigstore, or both? And expect other people to know both? What if they use 2 other systems they like, should I now use 4?

With PGP this all seems pretty obvious, and PGP signatures don't seem to be bad, right?

> The actual use cases for PGP are few and far between.

I use https://www.passwordstore.org/ with a hardware key on multiple OSes (including Linux, Android and macOS). I don't know of a better alternative to that.

No, I don't want to use 1Password. I want the UX of passwordstore. And I want to be able to somehow trust the password manager I use (if it comes from a random repo on the Internet, it's harder), and to somehow trust that it will still work in a few years. PGP has been around for decades, it feels pretty official and it should stay for a while, given that people have been trying to kill it for decades and complain that it can't seem to die :-).

I actually use pass in the same way, but to be fair gpg is doing some very basic pubkey crypto / HMAC in this case. Age or a sufficiently complicated openssl call could probably be swapped in if desired.

HSM agent features aside.

> ... could probably be swapped in if desired.

That's exactly my point! I do understand that in 2024, "we could probably do better than PGP if desired". But before complaining about people using PGP, maybe "we" should actually do it.

It is more convenient for me to use pass with PGP than to write my own alternative just because people complain about my using PGP, right?

What I'm saying is that PGP is an implementation detail as far as pass is concerned. Should the pass developers choose to switch it out I don't think there would be much visible change to the users.

Well that's a fundamental change that is exposed to the user: if you use pass, you need a PGP key. And if you don't know what a PGP key is, you should probably not use pass because you won't be able to use it on more than one computer and you won't be able to back it up.

If you want to use it with a hardware key, you fundamentally need to know how to configure that hardware key with a PGP key. If you want to use it on Android (there is "android-password-store" for that), you need to know how to handle a PGP key.

I recently discovered "passage", which is pass, but using age. If you want to use it with a hardware key, you need to setup a plugin (which is fine). If you want to use it on Android... I just don't think it exists yet (even without the hardware key).

What I'm saying is that it's easy to say that "it's completely stupid to use PGP nowadays", but my experience in practice is that there are some actual use-cases where I don't have an alternative. Telling me "sure, you should write and maintain the alternative" doesn't sound like a convincing way to tell me "you don't need PGP".

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.

One is messengers. I believe that Signal and similar modern systems (like MLS) do what they do better than PGP, because of forward secrecy.

But acknowledging the fact that I receive a lot of emails from a lot of services, it feels like it would be nice if those services had an option to encrypt the emails they send me with PGP. That way my email provider would not have access to their content, right?

So the thread model here is transactional emails? Don't modern services solve this problem just by HTTPS-linking back to the service?

> Don't modern services solve this problem just by HTTPS-linking back to the service?

Not all of them. That's actually a feature in GMail: it will populate your calendar from the information it reads in your confirmation emails, right?

I would argue that those modern services that send me a huge HTML-only email that only contains noise and a link to their website are downright annoying. It is very nice to receive a text-only update that contains useful information that I can read offline.

Reply on news.ycombinator.com