analysis and implementation of LRW

David Wagner daw at cs.berkeley.edu
Tue Jan 23 21:23:50 EST 2007


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 majordomo at metzdowd.com



More information about the cryptography mailing list