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].
OpenPGP has excellent recovery properties out of the box BTW...