I want to understand the issue here. I understand the bounds issue
with CBC and ECB, and as such are not relevant to this discussion
other than for history. The remainder is regarding LRW mode only...
My first statement is that I am not at all opposed to a statement
that this should only be used to write 2^64 blocks (listening
scenario) and to store 2^64 blocks (loss scenario) since most modes
leak after the birthday bounds. Stating the bounds in the standard
document helps the implementor since they can not not worry so much
about how long to use a key. What I have not heard is the clear
answer to the following passive attack (listening or loss) scenario...
Consider a single keyed space (partition if you like) that uses the
same key (K1 and K2). c = ciphertext, m= message, s = tweak. LRW
encryption is m=e(s,m)
First case, c1 == c2, s1==s2, we now have a dictionary entry since we
now know that m1==m2. This is important but well discussed listening
scenario.
Second case, c1 == c2, s1 != s2, can m1==m2? Aren't we dealing which
three permutations, (think an entire partition of the same m), this
can not happen, right?
Third case, c1 == c2, m1 != m2, s1 != s2. Does this case leak
information about K1, K2, m1 or m2? Might all we know is that m1 != m2?
Jim
On Jan 4, 2006, at 3:47 AM, Shai Halevi wrote:
(I will spare you the back-of-an-envelope
calculation of how long does it take to send 2^64 blocks over
a 100 Gbit/sec link.)
I think this argument is not very relivant. There was a time when
2^32
block was considered huge and 2^48 blocks was and impossibly large
size.
ok, so I will not spare you the calculation: it takes roughly 550
years
to send 2^64 blocks over a 128 Gbit/sec link. This says nothing
about the
time to compute things or protocol overhead, just the time to move the
raw bits over the link.
(2^64 * 16 * 8 bits) / (128 * 2^30 bits/sec) =2^34 seconds =544.77
years
-- Shai
