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

[Ray Dillinger]

On 02/11/2016 01:43 PM, Ron Garret wrote:

> On Feb 11, 2016, at 1:27 PM, Ray Dillinger <bear at sonic.net> wrote:

>> I propose instead "CXR mode", defined as
>>
>> Ciphertext = E(counter XOR Plaintext, key)
> 
> Or maybe:
> 
> Ciphertext = E(hash(counter+key) XOR plaintext, key)
> 
> Something about the (counter XOR Plaintext) makes me queasy, though I can’t offhand put my finger on what it is.

In order to exploit any properties about counter XOR plaintext, the
attacker would have to be able to spot patterns in plaintext by
looking at the ciphertext, or predict patterns in ciphertext based
on known properties of plaintext.

If the attacker can do either of those things -- at all -- then
your cipher is no damn good.

So CXR is fine on at least that count; it maintains the "at least
as secure as the cipher used" property, which is what we want from
cipher modes.  And the hash operation isn't all that cheap
compared to the encryption operation itself; it would slow the
combo down by at least 50%.

> But do you really need non-malleability at the level of an encryption block?  
> Why is it not enough to use an authenticated encryption mode with the 
> authenticator applied to a disk block?  That would seem to me to defeat 
> the malleability attack you’re suggesting while maintaining random access.

Well for one thing it's a hell of a lot simpler than an authenticated
encryption mode.

For another I'm happier if all attempts to modify the ciphertext are
guaranteed to produce garbage than I am if someone can modify
ciphertext in any way that results in the software being able to
determine what the attacker's intended modified plaintext was "but
it fails authentication." If that's possible, then a trojan horse
or an implementation failure will make it happen and fail to report
the authentication failure.

For a third thing it requires no authentication tag, which means
disk capacity doesn't get sucked up by something I don't care about
and I don't have to worry about handling extraneous bits in the
form of auth tags.

And for the last thing, this actually came up in a context where
each disk sector contains exactly one ciphertext block, so the
distinction between levels at which to achieve nonmalleability is
moot in the context of that discussion.

				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/feb2529b/attachment.sig>