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

[Ray Dillinger]

On 02/12/2016 10:16 AM, Bill Cox wrote:
> On Thu, Feb 11, 2016 at 9:54 PM, David Leon Gil <coruus at gmail.com> wrote:

> 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)

> 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.


You have a good point and you've convinced me of a necessary
revision of CXR - but the notion of "unintentional" is really
really funny when dealing with security.  You know that if CXR
as I first proposed it were to be deployed, this would happen
immediately and it would be as intentional as all getout.

But now we have to use a hash function on the counter, or at
least a nonlinearity of some kind, so the operation has gotten
significantly more expensive dangit.

				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/20160212/86bd40b8/attachment.sig>