The best-known problem with PGP is its poor usability, but that's not its biggest problem. It's biggest problem is an archaic design that literally predates much of modern cryptography; most egregiously, PGP is almost never forward-secret, and almost always relies on long-term keys, which is a deadly combination.

A more fundamental design issue is simply that cryptography engineers long ago abandoned the idea of a single toolset or even a single standard design that handles multiple problems. Messaging cryptography is not the same as backup cryptography, which in turn isn't the same as secure transports, or package update security.

More here: https://latacora.micro.blog/2019/07/16/the-pgp-problem.html

I don't think people want forward secrecy for their email. If they get a new computer, they probably want all their mail on there, right? Isn't porting over their email efficiently at odds with forward secrecy? Also, is forward secrecy compatible with any kind of encrypted search (I know most encrypted search schemes leak too much these days, but if the alternative is not encrypting email at all...)?

Also, how would it work with multiple people in a thread that can be added/removed arbitrarily, or email addresses that resolve to multiple users? Messaging and email seem like different models to begin with.

Keeping old messages around for all practical purposes negates forward secrecy in any messaging system. It isn't just an email issue. If they can get your secret key they can pretty much for sure get your old messages.

Most email users keep their messages in cloud storage (IMAP) so that changing computers is a non-issue. OpenPGP is an encrypt once scheme so that messages on an IMAP server are encrypted and stay encrypted.

Systems that lack forward secrecy are by design incapable of preventing archives of eventually-plaintext messages. There's nothing you can do about it; every message you send is irrevocably a part of the adversary's record, and, because you rely on a single long-term key, you know eventually that record will be plaintext. That's why forward secrecy is such a big deal, and why every modern messaging cryptosystem uses ephemeral keys.

But this only applies for messages that are deleted on your local device (either manually or through an automatic timer). Otherwise, whatever adversary stole your keys can steal your message archive too, they're on the same device. Now, assuming you aren't going to be deleting most of your mail, I don't see how forward secrecy is "such a big deal" in this scenario. It's certainly nice to have, but it definitely has drawbacks wrt the features I mentioned earlier.

Post-compromise security, on the other hand, makes more sense, since the future messages don't exist yet.

You can't meaningfully delete messages in non-forward-secret systems, because part of the premise of all these systems is that your adversary is recording everything.

I agree with you there. But is your point that any secure email system must critically have forward secrecy, or its insecure? Even though forward secrecy really only gives you any benefit for the messages that you delete, which most people don't in the context of email?

Just thinking, if people had the option between 1) deleting their mail and 2) email search, secure (unlike WhatsApp) and easy (unlike Signal) backups, ability to offload your email archive to the server (it's common to have gigabytes of mail, do you want to store all of it on a mobile phone forever? what happens if you drop it in a river?), and so on, don't you think people would go for option 2?

This is all disregarding the specifics of PGP-encrypted mail, for which I agree is not great.

The point is that one of the basic properties of messaging encryption is forward secrecy. It's an argument about how messaging is different from backup, package signing, file encryption, distributed logs, file transfer, and secure transports (though some of these really want forward secrecy too), and how PGP advocates back-rationalize not needing forward secrecy so they can defend their weird archaic tool.

Your argument is that forward secrecy is important in messaging because forward secrecy is important in messaging?

I'm not trying to be argumentative here, I actually don't understand what the reason it's so critical is, nor have I really found any explanations online. For text messaging where you don't really go back to read your old messages, sure, forward secrecy makes sense. Email seems to be a different story where user expectation is different and forward secrecy both precludes many desired features and also doesn't provide significantly more security, other than in very limited circumstances.

Also, I'm not an advocate of PGP at all. If people can use Signal for their usecase, great! They should do that. But Signal's model does not work for everyone's usecases. How do I send a Signal message to [email protected] to report a vulnerability? Is the entire security team supposed to share a mobile phone with Signal on it? What about banks that need to send secure email to each other, but must retain all messages for compliance purposes? (Again, I'm not advocating that PGP should be used in this scenario either, just that there's room for a better solution here, possibly without forward secrecy by default).

I'm not really sure what you're trying to say.

The premise of cryptographically secure messaging is that you have an adversary recording all your message traffic.

Lack of forward secrecy implies, logically, that if your long-term secret is ever compromised, every message you've ever sent is recoverable from the adversary's archive.

The point of forward secrecy is to break that attack, so that your adversary needs your long-term secret at the time it was used to send a message; having it after the fact doesn't help.

I'm sometimes in the mood to write long posts and comments explaining this stuff, but today, on the bottom of this old thread, if you're trying to make a point about PGP vs. Signal and don't know how forward secrecy works, I'm probably the wrong person to have this conversation with.

>The premise of cryptographically secure messaging is that you have an adversary recording all your message traffic.

Agreed.

>Lack of forward secrecy implies, logically, that if your long-term secret is ever compromised, every message you've ever sent is recoverable from the adversary's archive.

Also agreed. I am trying to say that this only gives you better security for messages that you have deleted on your device, because if you haven't, regardless of whether your protocol is forward-secret or not, the adversary that has the power to compromise your device will get access to the message the plaintext of which is on the device, even if the keys aren't. Thus, the scope is significantly limited, unless you have a policy to regularly delete old messages on your device, and most people do not want this for email.

I can assure you I understand the cryptographic properties of forward secrecy. I don't understand your claim that it is a strict requirement for every secure messaging system, including an email-like usecase.

>I'm sometimes in the mood to write long posts and comments explaining this stuff, but today, on the bottom of this old thread, if you're trying to make a point about PGP vs. Signal...

I already said several times I don't care about PGP. I feel like you're not really reading or responding to any of my arguments about why forward secrecy doesn't really help you much in most users' threat models or why it precludes various desirable features (of course, I could be wrong here, which is what I'm asking about). Thanks for your time anyway.

Again: without forward secrecy, you can't delete old messages, because your adversary has already recorded them. The point is that a lack of forward secrecy creates a subtle limit to the security that can be achieved.

Yes, that's exactly what we both agreed on 6 comments ago. The question is, is the ability to delete messages critical enough to require in any possible secure messaging solution, at the expense of features like email search, archiving, backup, and transfer-to-new-device?

Yes, it obviously is.

>Systems that lack forward secrecy are by design incapable of preventing archives of eventually-plaintext messages.

That is not what is being claimed here. Unless you add extra security in the form of something like a strong unique passphrase for the archived messages then an attack that gets the private key also gets the archived messages. In general, if you have a more secure method for protecting the archived messages you could of used it to protect the private key. It is effectively the same problem.

Adding to that, is there a forward secrecy solution to email? I believe this happens in TLS during negotiation, but a similar thing doesn't really exist in one-way communications.

Assuming you don't want to keep any "chain state" in between messages (which seems reasonable), you can always consume a fresh one-time key of the recipient for every message. The first downside is how you know that the one-time key hasn't been reused, for this you can either trust the service provider or use blockchain or blockchain-like technologies. Second downside is that the user has to be online to generate a ton of one-time keys. I believe puncturable encryption helps with this so the recipient can "puncture" their key at the used-up key identifiers, and thus doesn't have to be online all the time. No idea how practical this is.

What's your opinion on recent sequoia implementation? I've heard your arguments numerous times and was quite convinced, but that project and their offsprings (openpgp-ca, hagrid, ..) and other stuff like wkd seem to drag the ecosystem to something nicer. I consider it promising.

I think things written in Rust are better than things written in C. I think modern AEAD cryptography is better than the 90s cryptography that GPG uses. I think the PGP installed base mires the whole ecosystem in C code that accidentally goes quadratic just trying to parse keys, no matter what happens with Sequoia. It's a good project --- this TUI is probably a good project too --- but in a doomed ecosystem.

I am aware of these arguments. Still, GPG exists, and no one has really proposed good solutions, or at least the solutions that have been proposed are not taking off for some reason.

It is true that pointing out a problem does not need to be accompanied by a solution to be valid, but at this point, if you're going to complain please work towards solving the issue. It is too easy in this case to come off as someone who "knows things" while gesticulating at GPG in a derogatory manner while still accomplishing nothing.

> GPG exists, and no one has really proposed good solutions

[...]

> if you're going to complain please work towards solving the issue

Perhaps because you are asking the wrong question: "PGP/GPG is old, broken, and insecure, what is an exact drop-in replacement that I can substitute for it?"

Instead, the question should be: "PGP/GPG is old, broken, and insecure, what is a replacement for [this specific thing I am trying to accomplish with it]?:

So what are you trying to do with GPG? Sign a package? Encrypt a file? Store a backup? Transfer a file? Send a message? There are plenty of modern, secure solutions for these.

I know. I am aware of the appropriate questions and some (most) of their answers. But these things still do not seem to get adopted. Best I've seen is a few projects pick up signify. Signal is OK I guess, but still does not solve a lot of things a decentralized system can.

People always join these conversations to namedrop projects to sound smart and security conscious, apparently not having tried to integrate them into their existing workflows.

> these things still do not seem to get adopted

If I understand your comment correctly, the reason you are using an old, insecure, and broken tool is because the secure replacement is not as widely used?

Are you looking for some specific percentage of the population to adopt it? What is that threshold?

> Signal is OK I guess, but still does not solve a lot of things a decentralized system can.

Serious question: what problem does a decentralized tool that old, insecure, and broken solve that you would use it instead of one that is secure but "centralized"?

> People always join these conversations to namedrop projects to sound smart and security conscious

I can't judge other people's motivation for mentioning PGP/GPG alternatives, but the projects they mention certainly fit the criteria for being secure replacements. Are you going to disregard their answers because you have deemed their motivations unfit?

> apparently not having tried to integrate them into their existing workflows.

If you could explain your specific PGP/GPG workflow, perhaps someone might be able to suggest something to replace it.

Bunch of straw questions, I don't care to answer them. Answer your own pointless questions.

> Bunch of straw questions, I don't care to answer them. Answer your own pointless questions.

By "straw question", you are implying that I replaced your argument with a false one.

In the upstream comments, you agreed that PGP/GPG is broken and insecure. We have no difference of opinion there. You then stated that the reason you still continue to use it is because a) the alternatives are not getting adopted and b) are not decentralized. You also c) questioned the motives of people suggesting the alternatives, and d) stated that they have not used them in existing workflows.

All of these are things _you_ stated, I was careful to quote each point you made as I responded to them.

If I misstated your position or replaced it with a straw man, feel free to point out where I did that and I'll gladly correct myself.

GPG is broken and insecure‽

And old. See the many comments and articles posted in this thread to that effect.

Signal/WhatsApp/etc certainly seem to be taking off, and they seem to cover a broad swath of the use cases in messaging that people have historically tried to use GPG for.

It's always funny to see people talk about how important it is that PGP has an installed base and then think about how many PGP users there are compared to Signal Protocol users.

> The best-known problem with PGP is its poor usability, but that's not its biggest problem.

I don't know - if the design were more sounds from a crypto perspective, but it was still as easy to fuck up as the current interface, would it really be better?

Is there a way to do forward security in a non-interactive protocol (which seems necessary, if you want to communicate over email?)

I guess users could publish partial key exchanges out of band?

Don't use encrypted email. Encrypted email is deeply problematic, for many reasons having little to do with PGP.

https://latacora.micro.blog/2020/02/19/stop-using-encrypted....

This reminds me of my father's advice to every client (he had a corporate litigation practice):

"When you feel the urge to write an email, pick up the f*king phone instead. When in 5 years you're being cross-examined you can say 'I don't remember saying that' and you won't be lying, because we're too old to remember things, and I won't have to bill you for the time it takes to read all the f*king emails."

Thanks, interesting read.

It's scriptable, but scripting GPG is full of footguns. You generally want to do everything through status-fd to avoid most of the footguns, which is a pain to work with through ordinary shell scripts.