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]
