Hacker News Reader

Comment by forgotmypw17 | Hacker News Reader

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.

View on HN

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?

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.

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

Reply on news.ycombinator.com