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

[Bill Cox]

On Thu, Feb 11, 2016 at 9:54 PM, David Leon Gil <coruus at gmail.com> wrote:

> There's a lot of work on how to do block-level encryption well. I think
> the best approach would be to give up on disk encryption being
> non-expanding, and just use an AEAD mode (e.g., Chacha20-Poly1305) with a
> random IV. This is only 48-64 bytes overhead per block...


I'll second this, assuming that this works for this disk encryption
application we enough.  If using CXR mode on a UNIX system where users are
allowed somehow to read the encrypted disk contents, I can modify my
plaintext sector to be encrypted the same way as any other sector, and if I
just need to know if your data is A or B, I can figure that out in two
tries.

That said, I strongly prefer CTR to XTS mode.  XTS is malleable, and should
not be used.  Also, it has the same chosen plaintext attack, so CXR mode is
no worse in this case.  If we cannot have more bytes per sector for AEAD,
then I think I prefer CXR mode, simply because it is not malleable, even
with the chosen plaintext weaknesses.

It is not possible to avoid this chosen plaintext attack without an IV.
Without an IV, the attacker can always create cleartext that will encrypt
the same as your disk sector, if the attacker can guess what the cleartext
is.  So, if we can have extra bytes, use Chacha20-Poly1305.  Otherwise, I
recommend a slight change to CXR mode:

The case of storing incrementing binary numbers at the end of each sector
might actually occur now and then accidentally.  So, just use a simply
non-cryptographic function of the counter instead:

    Ciphertext = E(H(counter) XOR Plaintext, key)

Where H is something super-fast and simple, like:

   H(x) = (RAND_CONST ^ x) * ODD_RAND_CONST

This is a permutation for any RAND_COST, and odd ODD_RAND_CONST.  I would
not expect any unintentional collisions for large bit-lengths, but 64 bits
seems good enough.  A different H should be chosen for hardware-based
solutions.

Bill
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20160212/f78c09e9/attachment.html>