RE: p1619 (disk): Security concerns of LRW and an alternative mode

[Landon Noll]

Title: Message

I believe that the draft needs a section called "Limitations and Compromises" where issues such as what Matt Ball raised are addressed.  I believe that the draft is insufficient without documenting your "At that point the conclusion was that it does not buy us nearly anything" claim.  LRW is it stands now is a compromise with limitations (or weaknesses depending on your point of view) that some feel are needed.  Those compromises should be documented in writing so that the tradeoff can be understood by those who will be casting votes and by those who are participating in the working group.   I also believe that a rationale should be added to address this "LRW weak key" concern that people sometimes re-raise.  In FAQ form this might be:       Q x.y: Does not LRW <<insert Matt Ball's concern here>>?     A x.y: Yes, but <<insert that conclusion here>>.  For further information see section a.b in the "Limitations and Compromises" section.   chongo (Landon Curt Noll) /\oo/\ -----Original Message----- From: Serge Plotkin [mailto:[EMAIL PROTECTED] Sent: Thursday, December 22, 2005 5:37 PM To: SISWG Cc: Landon Noll Subject: RE: p1619 (disk): Security concerns of LRW and an alternative mode The proposal of using AES instead of GF multiply was discussed several years ago already. At that point the conclusion was that it does not buy us nearly anything but has higher implementation cost (GF multiply can be optimized for consecutive blocks). I did not hear anything new since these discussions.   -serge     -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Landon Noll Sent: Thursday, December 22, 2005 5:17 PM To: SISWG Subject: RE: p1619 (disk): Security concerns of LRW and an alternative mode   > This document discusses ways to attack LRW through algebraic weaknesses in > the Galois Multiplier.  This attack becomes strong if Key2 (K2) looks > similar to the plaintext (e.g. if K2 is an ASCII password).  The result of > this attack is to leak 128-bits of plaintext for each detected collision > (similar to ECB mode).    A covert channel within LRW is discussed. > Lastly, an alternative mode is proposed that eliminates these weaknesses. Matt Ball's alternative mode has merit and should be given some consideration. Regarding Shai's comment: > I strongly disagree that these are security issues. LRW (like pretty much > every crypto algorithm) needs random keys. If you use it with keys that > are not random, you deserve what's coming to you. There are many > established ways to derive cryptographic keys, and all of them are > adequate also for LRW. Needing random keys is insufficient in my opinion.  Simply saying "pick keys at random" is not a solution if weak keys under the current LRW proposal exist.  An advantage of Matt Bell’s proposal is that this potential weak key issue is bypassed. chongo (Landon Curt Noll) /\oo/\