[Cryptography] Justify the sequence of operations in CTR mode.

Ray Dillinger bear at sonic.net
Thu Feb 11 16:27:44 EST 2016


In considering attacks on disk encryption, I realized we've been doing
it wrong.  Our objectives with CTR mode are to obscure the relationship
between identical blocks while permitting random access (not requiring
reading/writing additional blocks when changing something in the
middle).

CTR mode encryption is defined as

Ciphertext = E(counter, key) XOR Plaintext.

This obscures the relationship between identical blocks and allows
random access, but leaves the data malleable.  If Mallory knows or
can guess the plaintext, he can XOR the ciphertext with a difference
vector to substitute a plaintext of his choice.

I propose instead "CXR mode", defined as

Ciphertext = E(counter XOR Plaintext, key)

Which also obscures the relationship between identical blocks and
permits random access, but leaves the data nonmalleable.  With CXR,
if Mallory has not the key, any change he makes to the ciphertext
block is overwhelmingly likely to result in garbage.

This is a particularly pointed question because Mallory usually knows
the plaintext at the crucial location which is the first software
that will be read for execution from the encrypted disk.  Its location
can be determined by looking at the non-encrypted portions of the
disk, or else bootup wouldn't work, and its plaintext can be guessed
by knowing what OS, distribution, or boot manager the user has
installed.  It will execute with root privileges early in bootup
with access to the encrypted filesystem, so substituting malware for
it is a ridiculously effective attack.

This is far too obvious for nobody to have thought of it before;
why aren't we doing it this way?

					Bear

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20160211/01c9c061/attachment.sig>


More information about the cryptography mailing list