4 ms·
CBC mode and its relatives, one of which is likely the mode you have in your head, is great for an ephemeral stream, but not well suited to permanent storage: i
by Chronos 17y ago
CBC mode and its relatives, one of which is likely the mode you have in your head, is great for an ephemeral stream, but not well suited to permanent storage: it's inappropriate for hard drives because it forbids random access, and it's inappropriate for tape drives because it makes the tape too lossy.
Real disks use either CTR mode or CFB mode, neither of which has those two problems.
CFB mode depends only on the previous cyphertext block to decode the current block, which allows random access but amplifies a one-bit error to a one-block error. CTR mode uses the current logical block number as IV salt, so it's both random access and minimally-corrupting in the case of errors. AFAIK most real-world hard drive encryption uses CTR mode, precisely to avoid the problem that concerns you.
- gnosis 17y agoThat's good to know. I'll have to look in to that. Thanks.
- tptacek 17y agoThis is an interesting comment, but it drastically oversimplifies the state of the art. An actually-good Wikipedia article: http://en.wikipedia.org/wiki/Disk_encryption_theory http://en.wikipedia.org/wiki/Disk_encryption_theory The short answer is, "use a well-known full disk encryption product, and don't worry about cipher modes".
- gnosis 17y agoThanks, but unfortunately that article does not address the issue of errors on the disk possibly making all the encrypted data un-decryptable.
- tptacek 17y agoWhat's the block cipher mode in which a small series of disk errors makes everything unencryptable? That doesn't even happen in CBC.
- rbanffy 17y agoOne could increase the redundancy by further reducing the data density. If all your data is encrypted twice on two different blocks, the odds a couple failed blocks renders all the data unreadable should be reduced. How would this impact the secrecy of the data?