Jim Hughes writes:
> The IEEE P1619 standard group has dropped LRW mode. It
has a vulnerability
> that that are collisions that will divulge the mixing
key which will reduce
> the mode to ECB.
Peter Gutmann asks:
> Is there any more information on this anywhere? I
haven't been able to find
> anything in the P1619 archives (or at least not under
an obvious heading).
Alexander Klimov replies:
>Probably <http://grouper.ieee.org/groups/1619/email/msg00962.ht
ml>
Huh. Was that the reason? I suspect there may have been
more to it
than that. The message at the cited URL basically says that
if the
attacker somehow manages to learn half of the key material,
then bad
things happen. That alone isn't likely to lead to rejecting
or accepting
a mode of operation, I would think. You know the old joke.
Patient:
"Doctor, doctor, it hurts if I let the attacker learn
part of my key."
Doctor: "Well, don't do that, then."
I should perhaps mention that there is some further
background which
no one has brought up yet, and which may help to understand
the IEEE
P1619 work. I know there was a concern on the IEEE P1619
mailing list
that, if the encryption key is sitting in memory, when you
suspend to
disk, if the suspend image is encrypted using that same key,
then you
are encrypting the key under itself (C = E(K,K)).
Encrypting the key
under itself is in general a potentially unsafe thing to do.
For one
thing, it voids the security warranty; every provable
security theorem
that I know of requires that the plaintext must not depend
on the key.
For another thing, with some modes, there are known attacks
where
encrypting the key under itself might reveal partial
information about
the key. LRW is one of those modes where there is such a
known weakness.
I understand that the IEEE P1619 group came to the
conclusion that it was
not reasonable to re-architect existing software to ensure
that it would
never encrypt the key under itself. This then creates a
requirement that
the mode of operation must be safe to use even when
encrypting a key
under itself. That is indeed an interesting requirement,
and one that
seems to legitimately rule out a number of existing modes of
operation
for IEEE P1619.
With that background, I want to circle back to the message
from Jim
Hughes. I was aware of this encrypt-a-key-under-itself
issue, and it's
an interesting one. But Jim Hughes didn't cite that as the
reason for
rejecting LRW; his mention of collisions made it sound to me
like he
may have been thinking of something else. Perhaps I
misunderstood his
intent. It might be helpful to have clarification on this:
Jim, were
you suggesting that there is a second issue, or have I
misunderstood you?
If there is an issue with collisions, I'd be interested to
understand
it better. Does anyone have any more information on this
anywhere?
Does this refer to the birthday bound issue, that if you use
a 128-bit
block cipher, then the security warranty is violated once
you encrypt
close to 2^64 blocks of data? Or is it something other than
that?
My apologies if I've totally misunderstood the P1619 group's
reasoning.
I suspect there may be a lot we can learn from IEEE P1619's
effort.
Thanks to everyone for their comments.
------------------------------------------------------------
---------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography"
to majordomo metzdowd.com
|