Laszlo, You are right in saying that when data and tweak key are related, we have problems. These and related issues were pointed out before several times, mostly by Shai. The tweak key should be a "real" key, with all consequences. Moreover, LRW should not be used to encrypt its own keys.
Nothing to be disappointed about. The way one should look at it is that data is "massaged" before and after ECB, where this "massaging" is independent of the data. -serge > -----Original Message----- > Frm: stds-p1619@LISTSERV.IEEE.ORG [mailto:[EMAIL PROTECTED] > On Behalf Of [EMAIL PROTECTED] > Sent: Monday, March 27, 2006 7:56 PM > To: [EMAIL PROTECTED] > Subject: RE: Data Accountability and Trust Act (link and definitions) > > You could try to sell LRW as just a variant of ECB, but I would really > be disappointed, if the certification authority buys that. One of the > many differences, which could cause security problems in some systems, > is when the tweak value t happens to be the same as the plaintext p. > LRW gives t (+) AES(p (+) t) = AES(0) (+) p. You required that the AES > key and the tweak key be independent, but when the plaintext data is > related to the tweak key and location, there could be a lot of strongly > correlated ciphertexts. One could try to extend the requirements, that > the data must be independent From the tweak values, but this would > imply, that LRW cannot handle all possible data. > > I don't mean it is a flaw in LRW, it is just a significant difference > between LRW and ECB. And there are many similar ones. > > Laszlo > > > -------- Original Message -------- > > Subject: RE: Data Accountability and Trust Act (link and definitions) > > Frm "Matt Ball" <[EMAIL PROTECTED]> > > Date: Mon, March 27, 2006 10:05 pm > > To: "Serge Plotkin" <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> > > > > RE: Data Accountability and Trust Act (link and definitions) > > > > Thanks Serge for helping to explain this. > > > > Everyone else, here is an exchange between Serge and me that the 1619 > reflector > > ate because it contained the string 'Frm :'. I'm resending it now, in > hopes > > that the reflector will take it. Please take a look below for the > entire thread. > > > > My last question before calling the issue closed is this: Are there > any FIPS 140-2 > > implementations out there that use LRW mode? This would provide the > precedent > > needed to show that LRW is considered ECB mode for purposes of FIPS > 140-2. > > Compliant FIPS implementations are list on the NIST website, so it > should just > > be a matter of pointing to one such implementation. > > > > Even so, it's probably worthwhile to submit LRW to NIST for > consideration as an > > 'approved mode of operation', if it hasn't already been done. > > > > Thanks, > > -Matt > > > > > > -----Original Message----- > > Frm Serge Plotkin > > Sent: Mon 3/27/2006 7:05 PM > > To: Matt Ball > > Subject: RE: Data Accountability and Trust Act (link and definitions) > > > > Unfortunately, the same way there is a big difference between reading > > written laws and practicing law, FIPS certification is a very > > complicated process. > > > > It is not really more "lax" than your interpretation. It is just > > different. > > > > > > > > In particular, although technically LRW is not ECB, it passes as "ECB" > > in FIPS certifications, as long as the multiplier key is derived > > independently Frm the AES key. > > > > Essentially, it is easy to claim that, under this restriction, LRW is > as > > strong or stronger than ECB, which is sufficient for FIPS purposes. > > > > > > > > -s > > > > > > > > > > > > _____ > > > > Frm Matt Ball > > Sent: Monday, March 27, 2006 5:53 PM > > To: Serge Plotkin > > Subject: RE: Data Accountability and Trust Act (link and definitions) > > > > > > > > Hi Serge, > > > > > > > > Concerning the e-mail reflector, I've had the same problems with > bounced > > e-mails. I discovered that it's possible to fix this problem by > > deleting all occurrences of the string 'Frm:' in the message body. > > > > > > > > Concerning FIPS certification, you are absolutely right: I've never > > actually gone through the FIPS certification process. All I've done is > > study the FIPS requirements documents. If there are unstated > > requirements, or if the validation labs tend to be lax, then that's a > > different story. I'd be very interested to know how many rules it's > > possible to bend before a validation lab denies FIPS certification! > > > > > > > > Just looking at the written requirements for FIPS 140-2, would you say > > my assessment is correct, or have I read something incorrectly? > > > > > > > > Thanks, > > > > -Matt > > > > -----Original Message----- > > Frm Serge Plotkin > > Sent: Monday, March 27, 2006 6:45 PM > > To: Matt Ball > > Subject: RE: Data Accountability and Trust Act (link and definitions) > > > > Matt, > > > > > > > > Somehow my messages are not going through the reflector, so this one is > > just for you. > > > > > > > > There is no problem at all certifying a well-engineered device that > uses > > LRW. > > > > I guess you were never involved in FIPS certification effort (were you > > ?) and thus you are making wrong assumptions. > > > > In general, talking about FIPS certification without going through the > > process usually does not work. This is why various certification labs > > are making so much money ! > > > > > > > > Having said this, of course I will support sending LRW to NIST for > > certification. > > > > > > > > -s > > > > > > > > > > > > > > > > > > _____ > > > > > > Frm Matt Ball > > Sent: Monday, March 27, 2006 5:41 PM > > To: Serge Plotkin; Cole, John (Civ, ARL/CISD); [EMAIL PROTECTED]; > > [EMAIL PROTECTED] > > Subject: RE: Data Accountability and Trust Act (link and definitions) > > > > > > > > Hi Serge, > > > > > > > > I could very well be wrong, but I haven't seen any compelling evidence > > yet on this reflector or on the web that NIST would allow LRW in a FIPS > > 140-2 compliant implementation. > > > > > > > > There was a series of e-mails on this topic back in January, with the > > subject line "RE: FIPS requirements (was Re: Can LRW be optimized for > > multiple sector keys?)". The only compelling argument that I read Frm > > that thread was Lazlo stating that 'LRW is not ECB mode'. I believe > > this is true, that LRW is not ECB mode, unless the tweak key is set to > > zero. Since LRW is not otherwise explicitly approved, I don't see how > > LRW could be FIPS compliant. > > > > > > > > FIPS 140-2 requires that "A cryptographic module shall implement at > > least one Approved security function used in an Approved mode of > > operation" (See FIPS 140-2 section 4.1, first paragraph). Appendix A > of > > FIPS 140-2 specifies these Approved security functions and Approved > > modes of operation. Here is a list of the approved modes: > > > > * AES in one of 5 modes-of-operation: ECB, CBC, CFB, OFB, and CTR > > (See SP800-38a) > > * DES and 3DES > > * Skipjack > > * DSA, RSA, and ECDSA > > * DES MAC and 3DES MAC > > * Enhanced Security DES MAC > > * CCM mode > > * SHA-1 and SHA-2 > > * HMAC > > > > I can't see any way that LRW fits into any of these categories. Could > > someone with better FIPS understanding please explain how an > > implementation that uses LRW mode would be approved for FIPS 140-2? > > > > > > > > Thanks, > > > > -Matt > > > > -----Original Message----- > > Frm Serge Plotkin > > Sent: Monday, March 27, 2006 6:07 PM > > To: Matt Ball; Cole, John (Civ, ARL/CISD); [EMAIL PROTECTED]; > > [EMAIL PROTECTED] > > Subject: RE: Data Accountability and Trust Act (link and definitions) > > > > Matt, > > > > > > > > Your statement is incorrect. > > > > In other words, use of LRW will not prevent a well-designed system to > > pass FIPS 140. > > > > > > > > -serge plotkin > > > > > > > > > > > > > > _____ > > > > > > Frm stds-p1619@listserv.ieee.org [mailto:[EMAIL PROTECTED] > > On Behalf Of Matt Ball > > Sent: Monday, March 27, 2006 4:57 PM > > To: Cole, John (Civ, ARL/CISD); [EMAIL PROTECTED]; [EMAIL PROTECTED] > > Subject: RE: Data Accountability and Trust Act (link and definitions) > > > > > > > > Hi All, > > > > > > > > These definitions are very interesting. It sounds like a cryptographic > > device will need to be certified for FIPS 140-2 (level 1) before the > > resulting ciphertext is legally considered 'encrypted'. > > > > > > > > The implication is that the LRW mode of P1619 will not be sufficient > for > > this requirement. To my knowledge, LRW is not an approved NIST > > mode-of-operation, nor does it even appear to be under consideration > > (see the absence of LRW at > > http://csrc.nist.gov/CryptoToolkit/modes/proposedmodes/index.html). > > Maybe we should submit LRW to NIST? > > > > > > > > For P1619.1, the outlook is a little sunnier. CCM is already an > > approved NIST mode, and GCM should be approved shortly. > > > > > > > > Does anyone have more information on this topic? The outcome of this > > legislation will potentially have a big impact on the direction of this > > working group. > > > > > > > > -Matt > > > > > > > > -----Original Message----- > > stds-p1619@LISTSERV.IEEE.ORG > > [mailto:[EMAIL PROTECTED] Behalf Of Cole, John (Civ, > > ARL/CISD) > > Sent: Monday, March 27, 2006 5:28 PM > > To: [EMAIL PROTECTED]; [EMAIL PROTECTED] > > Subject: Data Accountability and Trust Act (link and definitions) > > > > > > http://thomas.loc.gov/cgi-bin/query/z?c109:H.R.4127: > > > > SEC. 5. DEFINITIONS. > > > > In this Act the following definitions apply: > > > > (1) BREACH OF SECURITY- The term `breach of security' > > means the unauthorized acquisition of data in electronic form > containing > > personal information that establishes a reasonable basis to conclude > > that there is a significant risk of identity theft to the individual to > > whom the personal information relates. The encryption of such data, > > combined with appropriate safeguards of the keys necessary to enable > > decryption of such data, shall establish a presumption that no such > > reasonable basis exists. Any such presumption may be rebutted by facts > > demonstrating that the method of encryption has been or is likely to be > > compromised. > > > > (2) COMMISSION- The term `Commission' means the Federal > > Trade Commission. > > > > (3) DATA IN ELECTRONIC FORM- The term `data in > > electronic form' means any data stored electronically or digitally on > > any computer system or other database and includes recordable tapes and > > other mass storage devices. > > > > (4) ENCRYPTION- The term `encryption' means the > > protection of data in electronic form in storage or in transit using an > > encryption algorithm implemented within a validated cryptographic > module > > that has been approved by the National Institute of Standards and > > Technology or another comparable standards body recognized by the > > Commission, rendering such data indecipherable in the absence of > > associated cryptographic keys necessary to enable decryption of such > > data. Such encryption must include appropriate management and > safeguards > > of such keys to protect the integrity of the encryption. > > > > > > > > > >
