[tptacek]

Everything is better than PGP (not just GPG --- all PGP implementations).

The problem with PGP is that it's a Swiss Army Knife. It does too many things. The scissors on a Swiss Army Knife are useful in a pinch if you don't have real scissors, but tailors use real scissors.

Whatever it is you're trying to do with encryption, you should use the real tool designed for that task. Different tasks want altogether different cryptosystems with different tradeoffs. There's no one perfect multitasking tool.

When you look at the problem that way, surprisingly few real-world problems ask for "encrypt a file". People need backup, but backup demands backup cryptosystems, which do much more than just encrypt individual files. People need messaging, but messaging is wildly more complicated than file encryption. And of course people want packet signatures, ironically PGP's most mainstream usage, ironic because it relies on only a tiny fraction of PGP's functionality and still somehow doesn't work.

All that is before you get to the absolutely deranged 1990s design of PGP, which is a complex state machine that switches between different modes of operation based on attacker-controlled records (which are mostly invisible to users). Nothing modern looks like PGP, because PGP's underlying design predates modern cryptography. It survives only because nerds have a parasocial relationship with it.

[palata]

> It survives only because nerds have a parasocial relationship with it.

I really would like to replace PGP with the "better" tool, but:

* Using my Yubikey for signing (e.g. for git) has a better UX with PGP instead of SSH

* I have to use PGP to sign packages I send to Maven

Maybe I am a nerd emotionally attached to PGP, but after a year signing with SSH, I went back to PGP and it was so much better...

[computerfriend]

> better UX with PGP instead of SSH

This might be true of comparing GPG to SSH-via-PIV, but there's a better way with far superior UX: derive an SSH key from a FIDO2 slot on the YubiKey.

[palata]

I do it with FIDO2. It's inconvenient when having multiple Yubikeys (I always end up adding the entry manually with ssh-agent), and I have to touch the Yubikey everytime it signs. That makes it very annoying when rebasing a few tens of commits, for instance.

With GPG it just works.

[ahlCVA]

For what it's worth: You can set no-touch-required on a key (it's a generation-time option though).

[palata]

Sure, but then it is set to no-touch for every FIDO2 interaction I have. I don't want to touch for signing, but I want to touch when using it as a passkey, for instance.

[ahlCVA]

This is a per-credential setting, so you can have your SSH signing key be a no-touch key and still use touch confirmation for everything else.

(see "uv" option here https://fidoalliance.org/specs/fido-v2.0-ps-20190130/fido-cl... - the -sk key types in SSH are just a clever way of abusing the FIDO protocol to create a signing primitive)

[Avamander]

Use the PIV applet for SSH and signing Git commits instead? Git supports S/MIME and SSH can use keys over PKCS#11 basically out-of-box on OSs that don't ship gpg-agent (that just interferes with SmartCard usage in general).

[johnisgood]

Now can you give us a list of all the features of PGP and a tool that does one specific thing really well?

[some_furry]

https://soatok.blog/2024/11/15/what-to-use-instead-of-pgp/

I wrote this to answer this exact question last year.

[palata]

> The only downside to Sigstore is it hasn’t been widely adopted yet.

Which, from where I stand, means that PGP is the only viable solution because I don't have a choice. I can't replace PGP with Sigstore when publishing to Maven. It's nice to tell me I'm dumb because I use PGP, but really it's not my choice.

> Use SSH Signatures, not PGP signatures.

Here I guess it's just me being dumb on my own. Using SSH signatures with my Yubikeys (FIDO2) is very inconvenient. Using PGP signatures with my Yubikeys literally just works.

> Encrypted Email: Don’t encrypt email.

I like this one, I keep seeing it. Sounds like Apple's developer support: if I need to do something and ask for help, the answer is often: "Don't do it. We suggest you only use the stuff that just works and be happy about it".

Sometimes I have to use emails, and cryptographers say "in that case just send everything in plaintext because eventually some of your emails will be sent in plaintext anyway". Isn't it like saying "no need to use Signal, eventually the phone of one of your contacts will be compromised anyway"?

[Natanael_L]

The fact that every email encryption integration exports secure context messages into insecure contexts when decrypting (which is how encrypted messages end up cited in plaintext) means email can't be secured.

This is true both for GPG and S/MIME

Email encryption self-compromises itself in a way Signal doesn't

[some_furry]

> Which, from where I stand, means that PGP is the only viable solution because I don't have a choice.

You don't have a choice today. You could have a choice tomorrow if enough people demanded it.

Don't let PGP's convenience (in this context) pacify you from making a better world possible.

[palata]

I agree with that. But I feel like I have been reading for years that there is really no reason to use PGP, and I have tried for years to use alternatives, but the fact remains that I still need to use PGP, either because it is mandatory or because in some cases the alternatives are not practical.

To me, there will be no reason to use PGP the day I find practical alternatives for the remaining use-cases I have. And I feel like signing git commits is not a weird use-case...

[tptacek]

Does the GnuPG project sign its git commits with PGP?

[xeonmc]

offtopic question:

as a recent dabbling reader of introductory popsci content in cryptography, I've been wondering about what are the different segmentation of expert roles in the field?

e.g. in Filippo's blogpost about Age he clarified that he's not a cryptographer but rather a cryptography engineer, is that also what your role is, what are the concrete divisions of labor, and what other related but separate positions exists in the overall landscape?

where is the cutoff point of "don't roll your own crypto" in the different levels of expertise?

[Natanael_L]

There's no clear segmentation. There's symmetric and asymmetric primitives (and stuff that doesn't fit into these like ZKP), algorithms, protocols, research in many different types of attacks against each of these, research in design and defenses, and plenty of people will cover completely different subsets.

"don't" roll your own cover everything from "don't design your own primitive" to "don't make your own encryption algorithm/mode" to "don't make your own encryption protocol", to "don't reimplement an existing version of any of the above and just use an encryption library"

(and it's mostly "don't deploy your own", if you want to experiment that's fine)

[xeonmc]

I wonder if there is a concrete point at which it turn into “this is common sense security that even you should know about” like not conflating hashing and encryption, or “you should just have someone else do do security for you”? I guess at larger entities you have a CISO role but what about in smaller, scrappy endeavours, how does one know where one is at the limit of their due-commonsense and hand it off?

[tptacek]

Most practitioners in security --- from information security to compliance to systems security to software security to red-teaming --- have very little competence with cryptography. Cryptography is hyperspecialized. It is not part of the toolkit of any ordinary professional.

(That's nothing to do with how hard cryptography is, just with how little demand there is for serious cryptography engineering, especially compared with the population of people who have done serious academic study of it.)

[tptacek]

There isn't one, but the modal professional cryptography engineer probably has a graduate degree in cryptography.

[some_furry]

My job title is in the Security Engineer family.

I do not have a Ph.D in Cryptography (not even an honorary one), so I do not call myself a Cryptographer. (Though I sometimes use "Cryptografur" in informal contexts for the sake of the pun.)

[pseudohadamard]

What you actually want doing crypto is a security engineer, not a cryptographer. To quote Shamir's Law, "cryptography is bypassed, not attacked". No-one ever attacks the crypto, they attack the way it's used, so you need an experienced cryptoplumber to set it up correctly, not a cryptographer who will design a mathematically elegant whatsit and announce "there, solved!".

Ideally, this person will also design the system that uses the crypto, because no matter how skilled the people on a standards committee might be their product will always be, at best, a baroque nightmare with near-infinite attack surface, at worst an unusable pile of crap. IPsec vs. Wireguard is a prime example, but there are many others.

[xeonmc]

Interesting. In a general sense, where does it fall on the xkcd#435 scale?

[johnisgood]

You did not ask me, but you should do your due diligence because there are way too many armchair cryptographers around here.

[miki123211]

This is exactly that, in more detail than you could possibly ever ask for:

https://soatok.blog/2024/11/15/what-to-use-instead-of-pgp/

[akerl_]

https://www.latacora.com/blog/2019/07/16/the-pgp-problem/#th...

[jhgb]

> Use Signal. Or Wire, or WhatsApp, or some other Signal-protocol-based secure messenger.

That's a "great" idea considering the recent legal developments in the EU, which OpenPGP, as bad as it is, doesn't suffer from. It would be great if the author updated his advice into something more future-proof.

[akerl_]

There's no future-proof suggestion that's immune to the government declaring it a crime.

If you want a suggestion for secure messaging, it's Signal/WhatsApp. If you want to LARP at security with a handful of other folks, GPG is a fine way to do that.

[goldsteinq]

> If you want a suggestion for secure messaging, it's Signal/WhatsApp. If you want to LARP at security with a handful of other folks, GPG is a fine way to do that.

I want secure messaging, not encrypted SMS. I want my messages to sync properly between arbitrary number of devices. I want my messaging history to not be lost when I lose a device. I want not losing my messaging history to not be a paid feature. I want to not depend on a shady crypto company to send a message.

[tptacek]

I seriously don't care what messenger you use, as long as it isn't email, which can't be made secure. Pick something open source. It'll be less secure than Signal, but way more secure than email.

[Natanael_L]

Then your next best bet is Matrix.org. Not to the same security standard as Signal, but if you don't have a specific threat against you then it's fine.

[some_furry]

> I want secure messaging, not encrypted SMS.

I send long messages via Signal, typed on a desktop computer, all the time. (In fact, I almost exclusively use Signal through my desktop app.)

You don't have to use it like "encrypted SMS"! You're free.

> I want my messages to sync properly between arbitrary number of devices. I want my messaging history to not be lost when I lose a device.

OK. https://signal.org/blog/a-synchronized-start-for-linked-devi...

> I want not losing my messaging history to not be a paid feature.

I genuinely don't understand what you mean here. From https://signal.org/blog/introducing-secure-backups/

"If you do decide to opt in to secure backups, you’ll be able to securely back up all of your text messages and the last 45 days’ worth of media for free."

If you have a metric fuckton of messages, that does cost money, sure, but as they say:

"If you want to back up your media history beyond 45 days, as well as your message history, we also offer a paid subscription plan for US$1.99 per month."

"This is the first time we’ve offered a paid feature. The reason we’re doing this is simple: media requires a lot of storage, and storing and transferring large amounts of data is expensive. As a nonprofit that refuses to collect or sell your data, Signal needs to cover those costs differently than other tech organizations that offer similar products but support themselves by selling ads and monetizing data."

If you want Signal to host the encrypted storage, that costs money. If you don't want to pay Signal money, they provide 45 days of backup for free.

If you want to self-host your own backups (at your own cost), that's easy to do.

https://imgur.com/a/EIfaIee

You can literally set up SyncThing to stream your on-device backups to your NAS, cloud storage, or whatever.

> I want to not depend on a shady crypto company to send a message.

Shady crypto company?

Are you referring to MobileCoin? That feature isn't in the pipeline for sending messages.

I checked! https://soatok.blog/2025/02/18/reviewing-the-cryptography-us...

[jhgb]

Nobody decided that it's a crime, and it's unlikely to happen. Question is, what do you do with mandatory snooping of centralized proprietary services that renders them functionally useless aside from "just live with it". I was hoping for actual advice rather than a snarky non-response, yet here we are.

[Fnoord]

> Nobody decided that it's a crime, and it's unlikely to happen.

Which jurisdiction are you on about? [1] Pick your poison.

For example, UK has a law forcing suspects to cooperate. This law has been used to convict suspects who weren't cooperating.

NL does not, but police can use force to have a suspect unlock a device using finger or face.

[1] https://en.wikipedia.org/wiki/Key_disclosure_law

[closewith]

You're asking for a technical solution to a political problem.

The answer is not to live with it, but become politically active to try to support your principles. No software can save you from an authoritarian government - you can let that fantasy die.

[akerl_]

I gave you the answer that exists: I'm not aware of any existing or likely-to-exist secure messaging solution that would be a viable recommendation.

The available open-source options come nowhere close to the messaging security that Signal/Whatsapp provide. So you're left with either "find a way to access Signal after they pull out of whatever region has criminalized them operating with a backdoor on comms" or "pick any option that doesn't actually have strong messaging security".

[signed-log]

Most countries will throw you in jail for years if you refuse to give the password to encrypted devices they want. [1]

And that's even if you are innocent on the underlying charge or search.

Encryption in this political climate, is a pick your poison.

- Either you go to jail for years but you know your gov and other actors has no access to your data.

- or you store on remote/proprietary apps, stay free, but your gov or other actors may or may not have access to it.

[1]: https://en.wikipedia.org/wiki/Key_disclosure_law

[anonym29]

Could you please link the source code for the WhatsApp client, so that we can see the cryptographic keys aren't being stored and later uploaded to Meta's servers, completely defeating the entire point of Signal's E2EE implementation and ratchet protocol?

[akerl_]

This may shock you, but plenty of cutting-edge application security analysis doesn't start with source code.

There are many reasons, but one of them is that for the overwhelming majority of humans on the planet, their apps aren't being compiled from source on their device. So since you have to account for the fact that the app in the App Store may not be what's in some git repo, you may as well just start with the compiled/distributed app.

[johnisgood]

Saw it, not impressed, GnuPG has a lot of more features than signing and file encryption.

And there are lots of tools for file encryption anyways. I have a bash function using openssh, sometimes I use croc (also uses PAKE), etc.

I need an alternative to "gpg --encrypt --armor --recipient <foo>". :)

[akerl_]

I guess we'll have to live with you being unimpressed.

[some_furry]

> I need an alternative to "gpg --encrypt --armor --recipient <foo>"

That's literally age.

https://github.com/FiloSottile/age

[johnisgood]

No, because there is no keyring and you have to supply people's public key each time. It is not suitable for large-scale public key management (with unknown recipients), and it does not support automatic discovery, trust management. Age does NOT SUPPORT signing at all either.

[some_furry]

Why is a keyring important to you?

Would "fetch a short-lived age public key" serve your use case? If so, then an age plugin that build atop the AuxData feature in my Fediverse Public Key Directory spec might be a solution. https://github.com/fedi-e2ee/public-key-directory-specificat...

But either way, you shouldn't have long-lived public keys used for confidentiality. It's a bad design to do that.

[amluto]

> you have to supply people's public key each time

Keyrings are awful. I want to supply people’s public keys each time. I have never, in my entire time using cryptography, wanted my tool to guess or infer what key to verify with. (Heck, JOSE has a long history of bugs because it infers the key type, which is also a mistake.)

I have an actual commercial use case that receives messages (which are, awkwardly, files sent over various FTP-like protocols, sigh), decrypts and verifies them, and further processes them. This is fully automated and runs as a service. For horrible legacy reasons, the files are in PGP format. I know the public key with which they are signed (provisioned out of band) and I have the private key for decryption (again, provisioned out of band).

This would be approximately two lines of code using any sane crypto library [0], but there really isn’t an amazing GnuPG alternative that’s compatible enough.

But GnuPG has keyrings, and it really wants to use them and to find them in some home directory. And it wants to identify keys by 32-bit truncated hashes. And it wants to use Web of Trust. And it wants to support a zillion awful formats from the nineties using wildly insecure C code. All of this is actively counterproductive. Even ignoring potential implementation bugs, I have far more code to deal with key rings than actual gpg invocation for useful crypto.

[0] I should really not have to even think about the interaction between decryption and verification. Authenticated decryption should be one operation, or possibly two. But if it’s two, it’s one operation to decapsulate a session key and a second operation to perform authenticated decryption using that key.

[Natanael_L]

What you described IS WHY age is the better option.

GPG's keyring handling has also been a source of exploits. It's much safer to directly specify recipient rather than rely on things like short key IDs which can be bruteforced.

Automatic discovery simply isn't secure if you don't have an associated trust anchor. You need something similar to keybase or another form of PKI to do that. GPG's key servers are dangerous.

You technically can sign with age, but otherwise there's minisign and the SSH spec signing function

[pseudohadamard]

And when do you need any of that stuff?

As a followup, is there anything in existence that supports "large-scale public key management (with unknown recipients)"? Or "automatic discovery, trust management"? Even X.509 PKI at its most delusional doesn't claim to be able to do that.

[baobun]

sq (sequoia) should be able to sort that.

[johnisgood]

I know, I have been using it recently.

[benchloftbrunch]

What is the alternative to PGP for the specific use case of secure email? That doesn't mandate dealing with the X509 certificate bureaucracy?

[tptacek]

Don't encrypt email.

https://www.latacora.com/blog/2020/02/19/stop-using-encrypte...

[teddyh]

The only alternative suggested by the linked article is giving up email completely in favor of centralized solutions like Signal. My short answer is “no”. My long answer is: <https://news.ycombinator.com/item?id=45390332>

[tptacek]

I wrote the linked article. I don't care what secure messenger you use. But if you choose encrypted email over Signal because "centralization", you're LARPing. The first criteria for a secure messenger has to be that it is plausibly secure, and email isn't. You'd use encrypted email (for "decentralization") because you understand the cost of losing the plaintext of your message is nil. If you tell strangers to do that, without certainty that their messages are also valueless, you're committing malpractice.

[pseudohadamard]

Something that doesn't require securing email. Both S/MIME and PGP were solutions for 1980s problems (TFA is slightly off about PGP's start date, the PGP design dates from 1987 and MSDOS, not the 1990s, and S/MIME via PEM is from 1986). They're pretty much irrelevant today because almost all email is encrypted anyway via StartTLS and if you need full end-to-end encryption you use Signal or something similar.

[Natanael_L]

What's your usecase here? Internal or external messaging?

[pseudohadamard]

Use case? We're crypto LARPing dammit, we don't need a use case!

[josephg]

The thing I can't get past with PGP / GPG is that it tries to work around MITM attacks by encouraging users to place their social network on the public record (via public key attestation).

This is so insane to me. The whole point of using cryptography is to keep private information private. Its hard to think of ways PGP could fail more as a security / privacy tool.

[upofadown]

Do you mean keyservers? Keyservers have nothing to do with the identity verification required to prevent MITM attacks. There is only one method available for PGP. Comparison of key fingerprints/IDs.

Keyservers are simply a convenient way to get a public key (identity). Most people don't have to use them.