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
