It sticks around because it has some interface that users can use and is scriptable. Everyone saying GPG is bad usually has no general solution to replacing it.
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 guess users could publish partial key exchanges out of band?
https://latacora.micro.blog/2020/02/19/stop-using-encrypted....
"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."
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.
[...]
> 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.
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.
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.
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.
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?
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.
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.
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.
Post-compromise security, on the other hand, makes more sense, since the future messages don't exist yet.
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.
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 security@example.com 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).
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.
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.