Yes. Yessss. More.
Conversation
So like, it’s maybe worth picking apart what’s going on in this thread as opposed to just having cryptography hipsters dunk on it.
2
4
20
I “learned” cryptography back in the 1990s from Schneier’s Applied Cryptography, and what I remember most — all I remember really — from the cipher modes chapter was “some cipher modes give you error recovery and resynchronize after errors”.
1
19
Sounds like a good thing! Like, you don’t want a single bit error in your ciphertext to totally blow up your message?
Turns out, though, no, that’s exactly what you want.
4
2
38
The property we’re looking for, that any error — 1 bit, 10 bits, 1000 bits — blows up decryption, “authenticated encryption”. The original bits you produced from encryption _and only those bits_ can be decrypted with the right key.
1
2
20
There’s a bunch of theatrical examples of why this is the case. The best known is Vaudenay’s CBC Padding Oracle, where attackers could, by inducing errors in AES-encrypted blocks, decrypt whole messages under repeated trial decryption. Broke _TONS_ of real-world systems.
2
2
24
Replying to
A point of clarification you might want to add to the thread is that it's ok to apply error recovery (e.g. ECC) on top of the ciphertext, as long as you're properly authenticating the ciphertext and the decryption process itself does not tolerate bit errors.
1
2
It's supported as part of Android verified boot for the large high-level OS images. Here's an old post about it with the legacy verified boot implementation:
android-developers.googleblog.com/2016/07/strict
The high-level OS images are verified with dm-verity hash trees and dm-verity-fec is an option.
2
1
To be honest I was thinking of more simple scenarios, along the lines of encrypted files on a ZFS or RAID volume, or even just encrypted data being sent over 10G Ethernet (which has FEC).
1
2
Makes sense.
I think that verified boot usage is a nice example of explicitly deciding to do this, in a way that doesn't lose security beyond the small amount of attack surface needed for the error correction code. Can just store a parity file for an encrypted file alongside it.
1
i.e. encrypt file with age, then generate a parity file from the encrypted file. It's not the responsibility of age to deal with that at all. Ideally, the parity file is a super simple format with a memory safe implementation, etc. because it's added attack surface if it's used.