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.html>

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 [EMAIL PROTECTED]

Reply via email to