It is a serious problem that the ecosystem is held back by wasting resources on personal disputes with immediate consequences for end users.
Hate on OpenPGP all you want, it still is an important technology with unrealized potential and growth.
There is no breaking of backward compatibility. The crypto-refresh draft and the LibrePGP draft are equally backward-compatible.
See 'A Critique on “A Critique on the OpenPGP Updates”':
* https://blog.pgpkeys.eu/critique-critique
Both groups would create a new format (Libre = v5; crypto-refresh = v6). v4-only wouldn't be able to handle either new format, and newer software could presumably be told to create files in the older format.
The Proton folks are choosing to support both v5 and v6:
* https://github.com/ProtonMail/go-crypto/pull/182
As is the Thunderbird/RNP team:
* https://github.com/rnpgp/rnp/commit/fdfc1f5bb11d439e35f3c855...
(This is sidestepping the other parts of the comment that don't make sense, like why a single read implies multiple writes or why performing cryptographic upgrades is somehow uniquely, unacceptably risky from a data corruption perspective.)
It probably depends a lot on the application, but I think it's often much better to have something that will warn the user about security risks and let them decide what to do with that risk. If you do design something with these silent writes, you absolutely need to think hard about failure cases and test them, and not handwave them away. Having the most "secure" data be corrupted is ultimately an unacceptable outcome.
That's not even getting into the other problems, such as ... is it ok for the user to take a performance hit of writing X GB when all they want to do is read a file?
Put another way: your cryptosystem isn't responsible for saving your ass from not making backups. If your data is valuable, treat it that way.
This is exactly why your crypto system should not rely on spontaneously writing many gigabytes on a read operation, without asking. I couldn't have said it better myself.
What you are advocating is crypto intruding on the storage mechanism inappropriately. It's a layer violation.
I think if it's important to the end user, you could write fairly decent code at the app layer that asynchronously re-encrypts old data in a way that doesn't harm the user. That code would need to have a strategy for write failures. A basic cryptography tool should probably not have this as a built-in feature however, for a few reasons including those I've stated.
Again: nobody has said this.
Whether or not the tool does this in bulk, or asynchronously, or whatever else is not particularly important to me. The only concern I have in this conversation is whether it's contradictory to simultaneously assert the value of some data and refuse to encrypt it correctly. Which it is.
You said it. You said that's what the cryptosystem should do. It's a bad design.
From the original comment:
> This is sidestepping the other parts of the comment that don't make sense, like why a single read implies multiple writes
There is 100% value in being able to decrypt a 20 year old email. It doesn't matter if it is a broken cypher.
A 20 year old email has very little actionable in it, but can have value in other ways.
It is absolutely vital that a project like this, supports some means for a modern machine/stack to access older data.
Upstream spoke of deprecated support for older emails. My response is aimed there.
And there is loads of software that will not compile on modern hardware. End users don't often have that ability to re-write, or even to easily validate a random bit of code on github.
A project like this, needs to maintain backwards operability. For decades.
What's really being asked for here is the capability to seamlessly continue sending messages with the previous, weak constructions, into the indefinite future, and have the installed base of the system continue seamlessly reading them. I think that is in fact a goal of PGP, and one of its great weaknesses.
Users who still rely on that have to use the old software, against which there can be barriers:
- old executables don't run on newer OS (particularly in the Unix world).
- old source code won't build.
- old code won't retrieve the old data from the newer server it has been migrated do.
Things like that.
The barriers could be significant that even someone skilled and motivated such as myself would be discouraged.
Not all reliance is reasonable though.
Some legacy software can only do SSLv3 or lower, does that mean the rest of the internet has to carry that support around? Abso-f-lutely not.
The same applies here. If you really need that ancient stuff that loses support, repackage them in newer encryption or remove the obsolete layer. It's highly probable that information no longer needs to stay encrypted at rest anyways.
That is how it works. What you're missing is that everyone, both servers and clients, agrees that supporting old SSL versions is a bad idea. And they're right.
More precisely, I don't agree with web clients not connecting to old servers.
Plain HTTP is what people resort to when their browser refuses to connect to an old device or server using HTTPS, which is worse than old SSL.
The absurd idea that a user will have a 20 year old encrypted mail, because software still supports it, is ridiculous. What really happens is someone has a 20 year old mail no matter what, itcwill always exist, and the choice is, support it or not. Support it to be read, support it to be converted, warn the user, suggest fixes.
And your SSL example is senseless! In what world do you envision super secure stuff alongside weaker legacy, on the same damned server. You literally are not thinking sensibility about any of this, you examples are paper tigers.
This stance is absurb.
How do you alert the users that are running the problematic software and haven't yet updated it? The very premise is ridiculous.
> What really happens is someone has a 20 year old mail no matter what, itcwill always exist, and the choice is, support it or not. Support it to be read, support it to be converted, warn the user, suggest fixes.
Well yeah and the choice should be to not support it. If the user needs those letters they can either decrypt or just re-encrypt them. It's silly to claim that a message can somehow be both so vital to be protected by encryption, but not upgraded to something more modern.
> And your SSL example is senseless! In what world do you envision super secure stuff alongside weaker legacy, on the same damned server.
I'm not envisioning it. Nobody should be running such old useless garbage. What was suggested earlier in this thread does not work and must not happen in practice.
Where did you get the weird idea the software isn't updated? This entire discussion is about deprecation of older encryption methods in new versions of software.
You're not giving this thought. Good day.
In the trouble situations, one of the two pieces of software being upgraded is thrust upon the user.
Only when we are doing theatre. In the actual facts, lack of security is worse than inferior security.
Is there a real risk of this that I missed, or are you just free-associating off the term "backwards compatibility"?
The whole situation regarding key servers, key rotation, and the web of trust is a complete dumpster fire.
Can you explain why?
People elsewhere in this thread are saying that PGP sucks because it tries to do too many things at once, but it seems to me that the one big advantage of a tool which does everything at once is that you only need to solve authenticity one time for everything you do.
For example, if I'm communicating with an open source dev, having their known-authentic PGP key allows me to simultaneously verify the authenticity of their software updates, verify the authenticity of the email they send me, and encrypt my emails to them. Is there anything outside of PGP that accomplishes this?
Well, the key servers are useless because they are susceptible to that poisoning attack from a few years ago, and they happily send you fraudulent or revoked keys.
And the web of trust doesn't scale. The trust ratings mean different things to different people, the propagation of revocation certs and signatures is slow, and rotating keys is onerous.
>For example, if I'm communicating with an open source dev, having their known-authentic PGP key allows me to simultaneously verify the authenticity of their software updates, verify the authenticity of the email they send me, and encrypt my emails to them. Is there anything outside of PGP that accomplishes this?
How often do you check the fingerprints of that key? Do you verify out of band when the developer rotates their key? (Haha just kidding, PGP users essentially never rotate keys)
If you care enough to encrypt your emails, then what is the virtue of verifying less frequently that you're talking to the correct persons?
Why wouldn't you want separate keys for all those things?
Why would you want an adversary to be able to compromise a single key and have the ability to forge commits, emails, and whatever else?
I'm almost certain PGP best practice is to have a single master key, kept on an airgapped device, that's used to sign subkeys for various purposes like email, commit signing, etc. So I only have to verify out of band once, unless the airgapped device gets compromised or the master key encryption is broken.
More importantly, how do you know that your counterparty is one of that (extremely small) minority?
Don't forget about PGP smart cards either. You could keep the master key you use to sign subkeys on a smart card. A smart card should be harder to hack than your phone.
Qubes has built-in "split GPG" support that allows you to e.g. sign something using your private key while keeping it in a different VM. See https://www.qubes-os.org/doc/split-gpg/
I know PGP isn't for everyone, I just like the idea of keeping high-security options available for those who want them.
>More importantly, how do you know that your counterparty is one of that (extremely small) minority?
You could ask them :-)
But PGP doesn't provide a high-security anything.
- In order to achieve some reasonable level of protection from MITM attacks you can't just get someone's key from a keyserver. You have to go hunting for it and you're never really sure if there's a revocation cert out there that you just missed.
- Some people publish PGP keys on their websites, and you could use that to contact them over encrypted email. You are still vulnerable to metadata analysis and unless you manually re-key on every message (which you don't), you don't enjoy forward secrecy. Additionally, all it takes is one oopsie moment for someone to Reply-All and forget to encrypt first and now the entire conversation went out unencrypted. This has happened to me.
- You claim there's some unspecified benefit to signing commits with the same key you encrypt your emails with, though I don't see why that's superior to signify/minisign
- Best practices demand that you keep an airgapped machine with a long lived master key on it. No mention is made of how to prevent BadUSB-type attacks from jumping the air gap. If you really want to be sure nobody mints their own key from your airgapped machine to impersonate you, you now need to monitor your machine. That raspi in a drawer is still vulnerable to Evil Maid attacks, and the worst part is you won't know someone's impersonating you until it's too late.
All this attack surface just for the purported convenience of having some kind of unified "crypto identity" wherein you only need to verify someone once?
These are not the characteristics of a high security system. This is why people think PGP is a for security LARPers. It's objectively just not a very good tool.
This is a convenience consideration, not a security one.
>- Some people publish PGP keys on their websites, and you could use that to contact them over encrypted email. You are still vulnerable to metadata analysis and unless you manually re-key on every message (which you don't), you don't enjoy forward secrecy. Additionally, all it takes is one oopsie moment for someone to Reply-All and forget to encrypt first and now the entire conversation went out unencrypted. This has happened to me.
These are problems with encrypted email, not PGP. Encrypted email is not the only way to use PGP. See e.g. https://news.ycombinator.com/item?id=38575764
>No mention is made of how to prevent BadUSB-type attacks from jumping the air gap.
You could write newly minted keys to single-use CD-Rs.
>If you really want to be sure nobody mints their own key from your airgapped machine to impersonate you, you now need to monitor your machine. That raspi in a drawer is still vulnerable to Evil Maid attacks, and the worst part is you won't know someone's impersonating you until it's too late.
If physical access is part of your threat model, you'll want to monitor access to your stuff anyways.