Re: Counter Mode Security: Attacks, Storage & a Proposal

[Paul Koning <pkoning@equallogic.com>]

I continue to prefer a design where the transform strength is equal to
the cipher strength unconditionally, because that's (as far as I know)
the normal design rule.

I'm also somewhat hesitant to argue about your storage cost numbers,
but still, two observations...  

1. As I recall, the historical rate of capacity growth has not been
all that constant (unlike, say, the Moore's Law analog in processing
power).  Not all that many years ago the rate increased dramatically,
I believe.

2. The analysis assumes that hard drives are and continue to be the
most cost effective (YB/$) technology.  I'm not sure that's true now
(consider tape libraries) and it may not be true later.

If the goal is to reuse as much as possible of the proposed header
format, I would suggest a 32-bit random number, replacing both the
24-bit truncated SPI as well as the unused flags byte.

But I still prefer the 64 bit random number, keeping the best known
attack at O(2^128).

On the subject of the gigantic MTU proposal vs. the 16 bit block
number field: consider that we're talking about encrypted packets
here, so the question isn't just what sort of link speeds are
available, but also what encryption speeds are available.  100 Gb/s
seems plausible not too long from now; at a 1 MB MTU limit that
translates to a packet time of 125 microseconds.  That's quite a
civilized number.  At 1 Tb/s it becomes 12.5 microseconds, STILL a
very civilized number.  So a 1 MB MTU restriction for counter mode
isn't an issue.

(I would point out that the argument for larger MTU is partly valid,
in that packet times have dropped much too quickly.  But since all the
switch guts are very definitely getting much faster, there is no
reason to crank up MTU so much that packet time remains constant.  All
that's needed is that it drops no faster than the bottleneck rate of
the per-packet processing components of switches.  That's probably the
address lookup.  In 1992, on a 40 MHz processor, 10 microseconds
wasn't a big deal, so it's rather strange to argue that one should aim
for packet times substantially above one microsecond today.)

	 paul