Thanks to everyone who responded with more information about IEEE P1619. Here are some of the additional links, with my reactions:
Andrea Pasquinucci points to: > http://en.wikipedia.org/wiki/IEEE_P1619#LRW_issue Ben Laurie points to: > http://grouper.ieee.org/groups/1619/email/msg00558.html Wikipedia points to two concerns with LRW: (1) LRW isn't secure if you use it to encrypt part of the key; (2) something having to do with collisions. For these reasons, Wikipedia says that IEEE P1619 is moving to XEX-AES. I think (1) is a valid concern and a legitimate reason for IEEE P1619 to move to another mode. XEX-AES is a great mode and this seems like a solid move for IEEE P1619. XEX-AES rests on solid foundations, and there are good grounds for confidence in its design. I would add one caveat, though. I am not aware of any proof that XEX-AES -- or any other mode, for that matter -- is secure when used to encrypt its own key. This is not a flaw in XEX-AES, but rather a generic property of standard models of security for symmetric-key encryption. So I wouldn't be inclined to get too comfortable with the idea of encrypting the key under itself. I'm not 100% certain I follow what (2) is trying to get at, but it sounds to me like a non-issue. One interpretation of (2) is that the concern is that if part of the key is chosen in a non-uniform way (say, as a password), then LRW is insecure. Of course, you should not use any mode in that way, and I don't know of anyone who suggests otherwise. The remedy is straightforward: crypto keys should be truly uniform. This is standard advice that applies to all modes of operation. Another possible interpretation of (2) is that if you use LRW to encrypt close to 2^64 blocks of plaintext, and if you are using a 128-bit block cipher, then you have a significant chance of a birthday collision, which may leak partial information about the plaintext or key. That's absolutely true, though it is pretty much a standard feature of any mode of operation based on 128-bit block ciphers. Standard advice is to change keys long before that happens, and that advice doesn't seem terribly hard to follow. (See, e.g., my prior post on this subject for evidence that this doesn't seem likely to be a serious problem for current disk encryption applications. That's fortunate for narrow-block cryptography, because otherwise none of the solutions would be acceptable.) So it sounds like concern (2) is a bit of a red herring, and LRW is still ok for applications that won't be used to encrypt the key or any material derived from the key. The good news out of IEEE P1619 is that a number of excellent modes of operation are coming out of that effort, and other applications should be able to take advantage of the good work that P1619 is doing. This is good stuff. Disclaimer: Of course, LRW is of personal interest to me, so I'm sure I'm biased. Form your own opinions accordingly. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]