<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-size:small"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Jul 18, 2021 at 6:35 PM Ray Dillinger <<a href="mailto:bear@sonic.net">bear@sonic.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<br>
<br>
<div>On 7/18/21 12:11 AM, Natanael wrote:<br>
</div>
<blockquote type="cite">
<div dir="auto">
<div><br>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">Den sön 18 juli 2021
01:18Ray Dillinger <<a href="mailto:bear@sonic.net" target="_blank">bear@sonic.net</a>> skrev:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
<br>
Counter mode, classically, is P XOR E(Ctr) = C.
Using the same set<br>
of operations the same number of times each you can
implement a clearly<br>
superior counter mode E(P XOR Ctr) = C. <br>
</blockquote>
</div>
</div>
</div>
</blockquote>
...<br>
<blockquote type="cite">
<div dir="auto">
<div dir="auto">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. </div>
<div dir="auto"><br>
</div>
<div dir="auto">Either the counter must be pseudorandom or you
must use a different combiner like a keyed permutation (double
block cipher invocation per message block). </div>
<div dir="auto">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
</blockquote>
</div>
</div>
</div>
</blockquote>
<br>
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. <br>
<br>
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.<br>
<br>
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. <br></div></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">Congrats, you have essentially re-invented OCB.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">But that is fine because (1) Rogaway is a very smart guy and (2) this is probably how I would teach OCB mode if I do another crypto course.</div><br></div><div> </div></div></div>