On 7/18/21 12:11 AM, Natanael wrote:
Counter mode, classically, is P XOR E(Ctr) = C.
Using the same set
of operations the same number of times each you can
implement a clearly
superior counter mode E(P XOR Ctr) = C.
XOR is not a good combiner here for a plain
counter, P XOR Ctr exposes if the plaintext iterates (or
rather decreases) by the same value as the counter in between
blocks. If P goes down by one and Ctr up by one, C is
identical for the for the two blocks.
Either the counter must be pseudorandom or you
must use a different combiner like a keyed permutation (double
block cipher invocation per message block).
You are absolutely right. The counter needs to be obfuscated.
Still better than classic counter mode IMO, but the counter still
needs to be obfuscated.
So. Darn. The improvement requires at least one more
operation than classic XOR construction. I don't think the
additional operation needs to be as heavy as a cipher block
invocation though. I'd be happy with a relatively weak construction
for the counter, because it's sitting behind a block cipher
invocation. For example one could use a Mersenne Twister as a
counter, and that's pretty darn light.
With or without the additional expense of an obfuscated
counter, however, I'm going to stand by the assertion that nobody
should ever use Counter Mode, nor any XOR-construction stream
cipher, because every bit of ciphertext needs to be a function of
every bit of at least one decent-size block of plaintext.