Serge, I did not comment on "Adding a non-compliant KDF". I meant, whatever the standard will be, it would only gain wide acceptance in the industry (100 million implementations or more), if FIPS were updated. If a new KDF or LRW-AES, there is no difference in this regard, as long as the algorithm is provably secure.
>> delay in acceptance of LRW-AES by NIST WILL NOT prevent certification LRW-AES is using AES in a non-approved mode (until accepted by NIST), so it does prevent a FIPS 140-2 certification. One can create a tweak scheme, which is not secure, so a non-approved mode must always prevent FIPS certification. >> I suggest everybody on the committee to review FIPS 140 and CC documentation >> - will simplify discussions and reduce arguments I have seen nothing in the reflector that would be affected. What messages do you think could have been eliminated? Robert spoke about things, which would prevent FIPS certifications, and the dangers for being overly concerned about them. I explained the constraints of mass manufacturers. Laszlo > -------- Original Message -------- > Subject: RE: FIPS requirements (was Re: Can LRW be optimized for > multiple sector keys?) > From: "Serge Plotkin" <[EMAIL PROTECTED]> > Date: Tue, January 17, 2006 1:08 pm > To: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>, "[EMAIL PROTECTED]" > <[EMAIL PROTECTED]> > > Laszlo, > > I think you did not understand what Robert was saying. > Let me try to rephrase it: > > Adding a non-compliant KDF will PREVENT FIPS certification. > > On the other hand, delay in acceptance of LRW-AES by NIST > WILL NOT prevent certification. > > In general, I suggest everybody on the committee to review FIPS 140 and > CC documentation - will simplify discussions and reduce arguments in the > future. > > -serge > > > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of > [EMAIL PROTECTED] > Sent: Tuesday, January 17, 2006 8:53 AM > To: [EMAIL PROTECTED] > Subject: RE: FIPS requirements (was Re: Can LRW be optimized for > multiple sector keys?) > > In Crypto'05 I discussed these with the NIST security guys (John Kelsey > and William Burr). They said that NIST would consider adding new > algorithms and operational modes (LRW-AES), if they are standardized, > if there are a substantial number of industrial implementations, if > there is a consensus among experts that they are secure, if they find > no conflicts of interests, etc. > > This promise is very important to disk manufacturers, which want to keep > selling disk drives to government agencies. They probably will not > implement the proposed P1619 standard without FIPS approval. > > >> most vendors should be able to claim this is an ECB mode > But it is not. > > Laszlo > > -------- Original Message -------- > > Subject: Re: FIPS requirements (was Re: Can LRW be optimized for > > multiple sector keys?) > > From: Robert Sussland <[EMAIL PROTECTED]> > > Date: Tue, January 17, 2006 12:54 am > > To: [EMAIL PROTECTED] > > Cc: [EMAIL PROTECTED] > > > > On Jan 16, 2006, at 5:02 PM, [EMAIL PROTECTED] wrote: > > > > > For that matter: Is LRW-AES a FIPS approved algorithm used in a FIPS > > > approved mode of operation? > > No, I'm not aware of any work in this direction. However, most > > vendors should be able to claim this this is an ECB mode, for > > purposes of FIPS 140-2, depending, of course, on how the keys are > > obtained :) > > > > > FIPS 140-2 Annex A will have to be updated, > > > when P1619 becomes a standard, anyway. > > Absolutely not, and this is a dangerous view to hold, from the point > > of view of vendors that must be compatible with both FIPS and IEEE > > standards. > > > > NIST Federal Information Processing Standards (FIPS) are the only > > recognized crypto standards from the point of view of the U.S. > > Government, and NIST is under no compulsion to recognize ANSI, IEEE, > > ISO, or IETF crypto work as a FIPS, nor does it do so. Moreover, in > > those cases when an ANSI standard does influence a FIPS publication, > > the latter is often a modified and heavily subsetted version of the > > former, sometimes issued many years after the fact. To wit, compare > > the NIST SP 800-56 draft, and the ANSI X9 standards referenced > therein. > > > > For example, the recently updated Annex D to FIPS 140-2 explicitly > > disallowed the use of most ANSI key establishment protocols. This is > > evidence that NIST will not update Annex A as a result of P1619. Our > > hope is that NIST does not explicitly *disallow* P1619 when the > > standard is issued, and that there is substantial leeway to implement > > > LRW-AES in a FIPS compliant module. > > > > Requiring a KDF to derive symmetric crypto keys effectively kills > > this leeway. > > > > -Robert
