Hacker News Reader

> 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 which has a whole bunch of complexity you wouldn't have for signing RPM packages because it needs it, while RPM doesn't.

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.

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.

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.

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.

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.

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?

> It is a general-purpose text and binary encryption system

That's exactly why it shouldn't exist!

But why?

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.

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?

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.

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.

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.

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.

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.

> They’re all data with some attributes, and pgp handles them nicely, if you can write the interface for it.

This apparently almost wilful ignorance of the context of the "data with some attributes" is (specifically, how it's used), arguably, part of the problem.

It's been how many years, and still no-ones' written a good interface?

Nobody has written a good interface because PGP gets the primitives wrong. Most notably, the notion of long-term identifying keys you encrypt to directly as the most important service model.

I think it's a strong suggestion that should be ignored.

Using PGP with disposable keys.

These things take a while sometimes.

They're very different.

Take forward secrecy. This is a property that means that if your key is compromised, it doesn't allow breaking everything you've done with it. This is a very desirable property for email or messaging because you don't want somebody reading all your conversations if somebody ever gets their hands on your key.

Or take non-repudiation. This means that when you sign a message you say "John Smith did this", and John Smith can't deny having done it.

For email or IM we want forward secrecy. You don't want all your conversations to become readable if anyone ever gets their hands on your keys. If you're caught, you don't want the authorities to be read your entire conversation about obtaining drugs, you want a system such that even if they get your phone, they still can't decrypt your captured encrypted messages. GPG isn't capable of this.

For email or IM we don't want non-repudiation a lot of the time. If you're caught, you don't want every message being "Signed, John Smith". GPG provides non-repudiation, which is undesirable.

On the other hand, we don't want this for package signing. We want to know that John Smith released this thing. We want to hold John Smith to account if he signs a malicious package, that's the very point of John Smith signing it.

I don't want forward secrecy for my email. I actually want to keep my archived emails for an indefinite period. PGP allows me to do this in relative safety, the email is encrypted once at creation time an then stays encrypted. In general, forward secrecy does not work for the case where someone keeps the message. If the attacker can own a user well enough to get their secret key material, they will also get any messages that user still has access to.

Things might be different for a relatively insecure medium like IM but the same principle applies. Most IM users keep their old messages around thus negating the value of forward secrecy.

>For email or IM we don't want non-repudiation a lot of the time.

We might not, but the people we send our messages to will want to prove we sent it. Otherwise you open yourself to harassment and general abuse. If you don't want to sign your emails then you don't have to. Deniability through claimed forgery doesn't really work anyway:

* https://articles.59.ca/doku.php?id=pgpfan:repudiability

The lack of forward secrecy in PGP means that you can't protect your secrets long term; having forward secrecy, meanwhile, wouldn't prevent you from machine arrangements to securely archive. This is so straightforwardly obvious that it's hard to believe this response is made in good faith.

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.

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.

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

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

For signing minisign, signify, and OpenSSH exist; most of them have been around for quite a while (OpenSSH signing is the only one that's relatively new).

They're not "alternatives to PGP" in the sense that they will do everything PGP can (notably, no encryption). But that's not really a bad thing, IMO, and for encryption alternatives exist too.

One of the problems that ecosystem support is often lacking, both for signing and encryption. git can sign with OpenSSH since last year, but that's one of the exceptions. But that doesn't mean alternatives don't exist.

Ecosystem support is hard; you need to convince untold authors of software to implement your new crypto thingymabob, and there's a "well, no one supports it yet, so why should I?" catch-22 here.

> without offering a better alternative

On the one hand, I sort of agree with you, I think the disadvantages of current PGP tools are overstated. But I think there are some plausible alternatives depending on your use case. They just aren't bundled into a single tool.

For file encryption, there's age. This uses all modern crypto and does authenticated encryption.

For signing, there's signify. I wonder if age and signify can be made to use the same keys...?

For live two-party encryption, there are protocols appropriate to the use case. Axolotl for chat, Wormhole for file transfers.

For PKI, there's... whatever people actually do instead of PGP keyservers and WoT, because they've never been a reliable way to find out someone's public key. In practice, you'd either download it from someone's website, get it off a keyring, receive it through some other secure channel, or be given it in person.

It's ironic that people make the argument "the reason no one uses PGP is that it doesn't have network effects, and the reason it can't build a network is that it sucks", because the thing keeping me on PGP is its network effects. In the circles I run in, you can count on people having PGP keys and knowing how to use them for encryption and signing. They've been used in Linux packaging for years, for example. I can't count on someone using age, at least not yet.

> For file encryption, there's age. This uses all modern crypto and does authenticated encryption.

GnuPG offers AEAD encryption since version 2.3.0.

Is it the default? That's all that matters. When GPG defaults to AEAD ciphers, you can say that the ecosystem really supports AEAD (GPG is the de facto reference implementation). If it's not the default, that's purely because too much of the installed base doesn't do AEAD --- there's no other reason to default to PGP's pitiful MDC construction.

GnuPG has offered authenticated encryption for 20+ years now along with everything else that implements the OpenPGP standard.

> Yet it is the most stable, the most open, the most proven, and the most supported PKI technology, supporting both encryption and signatures.

You're completely ignoring the CA system used for TLS. In the niche segment of encrypted/signed email, S/MIME sees an order of magnitude or two more use than PGP. Even DNSSEC, for all its issues, is probably more used than PGP.

The other really obvious comparison is Signal, which secures more messages in a week than PGP/GPG has in its entire lifespan.

I hate to have to point this out, but in the spirit of technical correctness: as bad as PGP is, it would still be a pretty big deal if it was totally broken (like, at the core, rather than its email use case, which Efail did catastrophically break). People would have to do things in response. But I maintain that if DNSSEC had a comparable failure, nobody would even need to be paged; literally nothing important meaningfully relies on it. It's almost perfectly performative.

Signal is controlled by one entity and supports 3.5 of the biggest platforms and does not provide libraries for third-party code.

Most people who use Signal are getting a closed-source binary.

I don’t see how it can even be compared to pgp.

I don't see them as meaningful competitors either, but not for the reasons you're giving.

CA is centralized and suffers from all the drawbacks of being such, including but not limited to censorship, lack of privacy, and centralization itself.

I don’t understand how it can be even seen as an alternative to something like pgp

It's a PKI system, and by far the most widely used PKI system at that. Calling PGP "the most proven, and most supported PKI technology" is just simply not factual. You may not like it, but that is no reason to disregard understanding why it is so successful and something like PGP languishes with basically no usage in comparison.

(As a rough estimate, there's something like 10,000-100,000 PGP users.)

Could you please explain how you came up with your estimate?

I’m pretty sure I’ve met that many pgp users without leaving my little corner of the world, which is not sv

The size of the keyrings of global PGP servers is knowable. I don't have a link to the analysis from which I draw the numbers, but the summary is about 100k PGP keys. Take into account unusable keys and duplicates, and some number in the (probably high) tens of thousands is a reasonable estimate for PGP users.

In terms of anecdata, the only people I've known to have used PGP where the ones working on supporting it in the email client; I've seen more evidence of S/MIME email than PGP, and even that is extremely thin on the ground.

FWIW, I use PGP daily and haven't touched a keyserver in a decade.