The high bit of the right answer to this question is that you don't want to replace PGP; one of the things we've learned in 29 years is that you don't want a single tool to do lots of different cryptographic things, because different applications have different cryptographic needs.
For package signing: use something in the signify/minisign family.
To encrypt a network transport, use WireGuard.
To protect a web transaction on the wire, TLS 1.3.
For transferring files: use Magic Wormhole.
For backups: use something like Tarsnap or restic.
For messaging: use something that does Signal Protocol.
To protect files at rest, use encrypted DMGs (or your OS's equivalent, like encrypted loop mounts).
To encrypt individual files --- a niche ask --- use Filippo's ungooglable "age".
It would be nice if there was a reasonable baseline of key format/management that all these new tools shared though. And I don't mean pgp/gpg keyrings, to be clear, which are cumbersome and error prone and over-complicated for a lot of these needs (I'm still annoyed that `pass` is reliant on gpg for forcing me to deal with a keyring).
I see that `age`, which I hadn't actually heard of before, supports ssh keys and identities which always seemed like a fairly natural baseline to me. Would be nice if more of the command line variety did as well (even if only rsa and/or ed25519 keys).
Why? Why is that good? One of the basic cardinal sins of cryptography is using the same key in more than one context. I don't understand the value of the SSH thing, either.
I don't want to use the same key in multiple contexts, but I think some norms around how keys are stored would help build best practices around them.
It would also potentially mean easier to use with hardware tokens, if you could just expect to be able to use something like gpg-agent or ssh-agent or something in between to work with various things.
Last I looked "age" did not have any sort of recovery utility. It isn't even clear that such a utility is possible (the protocol is poorly documented). A single bit error at the start of the file causes the loss of the entire file. So be careful using it for any sort of thing that might ever require the sort of recovery that bzip2 or lzip provides (gzip has a third party recovery utility).
OpenPGP has excellent recovery properties out of the box BTW...
I want to be sure I'm reading this correctly. Failing to decrypt on a single bit error is the literal job definition of authenticated encryption. Any error you accept is malleability conceded to an attacker. Are you complaining that age isn't malleable enough?
If I run a file through age, and then run that through a Reed-Solomon encoder, I now have a file that can be decoded even with single bit errors. But I think I also still have authenticated encryption. The cost is that my file takes a bit of extra space.
You are not. Of course, the problem is that PGP doesn't get its informal resilience to single-bit errors through error-correcting codes on the ciphertext.
To be clear, OpenPGP does not correct errors. You still end up with corrupted data. It is just that you get back all your good data, no matter where it is in the file.
So you're saying that not only does OpenPGP release unauthenticated plaintext to callers, but it doesn't even implement the feature that takes advantage of it. Good note.
What's crazy about this is that you can get error correction without using insecure 1990s cryptography, simply by forward error correcting your ciphertext. I'm really having a hard time even getting my head around the argument you've managed to devise here.
>Failing to decrypt on a single bit error is the literal job definition of authenticated encryption.
Yes, this is an excellent example of where this behaviour is suboptimal. We should not cargo cult authenticated encryption. It has its place but this isn't it.
> Any error you accept is malleability conceded to an attacker.
Sure, but malleability that has a close to zero chance of being a problem. We are talking about static encryption here. You only get one chance at malleability and the user immediately knows something has gone wrong:
gpg: WARNING: encrypted message has been manipulated!
>Are you complaining that age isn't malleable enough?
Merely pointing out that for the most common use case age is objectively worse than GPG.
I think you are doing a fine job of advocating the position that PGP is the cryptosystem of choice for people who believe authenticated encryption is a cargo cult.
The logic you're applying here about how GPG can warn you if it has employed "recovery properties" to correct "single bit errors" was embraced enthusiastically by the Ruhr team to perform data recovery on other people's PGP-encrypted email messages.
Efail is an excellent example of how the static encryption of OpenPGP used for encrypted email makes malleability irrelevant. To make the Efail attack against OpenPGP work requires the knowledge of the first 11 bytes/characters of the unencrypted message. The attacker would only get one guess. The recipient by necessity would see the attack message and would immediately know there was something going on. As a result the Efail attack against the malleability of OpenPGP is completely impractical.
Contrast the Efail situation with that of TLS. TLS allows almost unlimited secret trials against its cryptography by an attacker. There have been multiple practical attacks based on such oracles in TLS.
>This isn't even a controversy among cryptographers or cryptography engineers.
I would like to think that there were such people out there that understood that different techniques are applicable to different problems.
You can just read the Efail paper and see how faulty this argument is. Because PGP treats authenticated ciphers as a "cargo cult", the Efail team could plausibly have broken almost 40% of Facebook's PGP-encrypted password reset mails. Further: they were able to abuse MIME encoding to get multiple guesses per email.
At any rate, none of this is something that anyone would accept from any modern cryptosystem, and the fact that PGP has you so backfooted that you'd feel the need to defend PGP's behavior here is a telling indication. "PGP: it's fine, as long as you don't use it to encrypt password reset emails. But for other emails it's fine, as long as the first 11 bytes of the email aren't guessable." Ok. Good note!
Maybe we should just put 128-bit nonces at the tops of all our emails. That just seems like common sense good engineering practice.
>Further: they were able to abuse MIME encoding to get multiple guesses per email.
The paper did not provide any example of an email client where this would work. I have as of yet not been able to reproduce this. Since there would be no practical reason for such behaviour the assertion requires some sort of proof.
I am not suggesting that email clients should entirely depend on OpenPGP email inherent resistance to oracle attacks, only pointing out that it exists. Presumably the Enigma operators were not putting their decrypted messages in envelopes before sending them off to their enemies. Efail was primarily a straight up plain text leak.
Plain text attacks come in distinct categories. The block ciphers used in OpenPGP are generally considered to be immune to the sort of plain text attacks used against Enigma.
I think when you're at the point in your argument where the bar you're setting is "immunity to the attacks that broke Enigma", you might as well just concede.
OpenPGP specifies cipher feed back (CFB) mode[1] for block ciphers (normally AES). CFB has the inherent property that it is self healing in the face of corruption. It does not work in all possible instances of corruption but it works for the normal sort of corruption that is seen with mass storage devices (multiples of 512 bytes). A practical example here[2].
I find "age" a bit awkward when it comes to handling private keys. I want to store my private key files encrypted. If it just would accept private key files that have been encrypted with a passphrase it would be almost perfect.
There are ways to work around this [1], but I'm not happy with any of them.
Which of these do I use to send encrypted messages to darknet vendors based on well-known public keys shared through Reddit etc? This is the number one use case of PGP for me and it doesn't seem to be solved by any of these other tools.
It is maddeningly difficult to simply encrypt a file with interoperable tools. I'm optimistic about age, but it's early days. I understand why people want to use 7z for this. The problem is, if anyone else tries to send you an encrypted zip, and they use something other than 7z, they will likely end up using something even worse than Bass-O-Matic; the zip encryption ecosystem is unbelievably horrible, and it's intractably difficult for ordinary people to know what they're getting. So: long story short, I would tell a client "never, ever use encrypted zips".
For package signing: use something in the signify/minisign family.
To encrypt a network transport, use WireGuard.
To protect a web transaction on the wire, TLS 1.3.
For transferring files: use Magic Wormhole.
For backups: use something like Tarsnap or restic.
For messaging: use something that does Signal Protocol.
To protect files at rest, use encrypted DMGs (or your OS's equivalent, like encrypted loop mounts).
To encrypt individual files --- a niche ask --- use Filippo's ungooglable "age".