<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Feb 11, 2016 at 9:54 PM, David Leon Gil <span dir="ltr"><<a href="mailto:coruus@gmail.com" target="_blank">coruus@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">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...</blockquote><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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:</div><div><br></div><div>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:</div><div><br></div><div>    Ciphertext = E(H(counter) XOR Plaintext, key)  </div><div><br></div><div>Where H is something super-fast and simple, like:</div><div><br></div><div>   H(x) = (RAND_CONST ^ x) * ODD_RAND_CONST</div><div><br></div><div>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.</div><div><br></div><div>Bill</div></div></div></div>