5

If a non-encrypted document has a corrupt byte - we only get a typo. But what about an encrypted file? It seems, and please correct me if I'm wrong, that if the encryption is done right - every byte depends on the previous bytes. This raises a concern. If I make a disk image and have it done with encryption - perhaps there's a non-negligible chance that I won't be able to restore it.

I understand that even if I'm right - an exact answer will depend on the media type, age, etc. and even then - be quite a guesstimate. But I would like to have at least an order of magnitude of the prevalence of errors. (Or if my original assumption is wrong - I'd like to know that, of course.)

  • For disk files, you probably get an unrecoverable read error on the block with the corrupt byte, and so lose 512 bytes or more. – Bob Brown Dec 23 '14 at 18:39
1

That depends entirely on the cryptographic algorithm used. One of Claude Shannon's maxims was that errors should not propagate. In the case of AES in CBC mode, a single bit error will propagate to two blocks.

Modern cryptosystems are likely to use a digest or other message integrity mechanism to detect tampering, so that in case of an error in the encrypted data, the entire ciphertext will be rejected on the basis that a mismatched digest suggests tampering.

Modern computing hardware is so robust that it probably doesn't make sense to worry much about errors. if error correction is an important consideration, then data should have error-correcting codes added before encryption. In that way, errors in the decrypted data can be corrected. However, if decrypted data is accepted despite a non-matching digest, then tampering can no longer be detected.

Edit: Now that I think about it a {ahem} bit, a bit error in encrypted data is no more likely than a bit error in plaintext. If you accept that a single-bit error renders an entire physical block of the disk unreadable, then a bit error in encrypted data the propagates to the next 128-bit block (AES, CBC) will also result in loss of a single 512-byte disk block 31 out of 32 times, and at most two physical disk blocks in the 1/32 case that's left. Unless I've missed something in the probabilities, for 512-byte physical blocks, a bit-error in encryption corrupts one block 97% of the time and two blocks the remaining 3% of the time.

If you also accept that a single unreadable physical block means the file is effectively destroyed, then there's no error-rate penalty for encryption.

In any case, one defends against unreadable ciphertext in the same way one defends against unreadable plaintext: RAID and backup copies of files, being physically careful of disk drives, etc.

  • 1
    Thanks. Modern computing hardware is so robust ... - Any statistics on this? (1 bit in 100GB might break a disk image.) – ispiro Dec 23 '14 at 18:41
  • 1
    According to Microsoft, SATA disks can experience one bit error per ten terabytes, but they also suggest Mean Time to Data Loss as a more meaningful metric: research.microsoft.com/apps/pubs/default.aspx?id=64599 – Bob Brown Dec 23 '14 at 18:44
  • 2
    Wouldn't it make more sense to apply an ECC to the ciphertext, if you're worried about errors in storage or transmission? An ECC on the plaintext only helps if you think it might be corrupted before encryption or after decryption (and in the latter case, you can add it when you decrypt); if you're worried about corruption while it's encrypted, you want an ECC on the ciphertext to protect against that (you'd do all your crypto first, and then use an ECC on the whole thing). – cpast Dec 23 '14 at 19:30
  • @cpast: Maybe. If you can prevent/correct errors in the ciphertext, then there's no problem. (See the last paragraph of my edited answer.) Applying ECC to the plaintext before enciphering allows for correction of a bit error even if the error is propagated by the decryption algorithm. In other words, ECC on the plaintext can undo damage caused by decryption. I'm not enough of a statistician to calculate the probabilities either way. – Bob Brown Dec 23 '14 at 19:34

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.