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
