Folks,
Let us pay attention to some of these P1619 so-called "pink herrings"!
> I have not received any meaningful response to the issue of
> grandma storing her keys on an encrypted drive. The WG must
> have considered it the first time it came up ...
I have not spoken up until now because I thought a "me too"
message would not add to the discussion until now.
Draft 5, section C.5, 3rd bullet point states:
* As with most cryptographic algorithms, LRW-AES transform
should not be used to encrypt its own secret-key. In
particular, when using LRW-AES to encrypt its own secret-key
followed by a block of zeros, it may be possible to deduce
the last 128 bits of the key from the ciphertext.
BTW: I believe the cryptological attack might be possible
if the LRW-AES secret key is also preceded
by a block of zeros, not just if it is followed by zeros.
I would like to explore how the LRW mode can be improved to mitigate
this problem.
I would also like to explore the possibility of constructing attacks
where the LRW-AES secret-key is preceded or followed by a known and
chosen
non-zero (perhaps a low hamming weight (low number of 1 bits)) block
of data. I am not convinced that some form of interesting attack with
a low hamming weight block is out of the question. The more general
problem might be somewhat wider than we suspect.
chongo () /\oo/\
=-=
p.s. Editorial (rat-hole warning) side note:
Given the level of issues that some people saw in some
bad implementations and mis-uses of CBC mode, I'm still
amazed at how easy LRW passed the working group with this
kind of issue hanging over it.
