For that matter: Is LRW-AES a FIPS approved algorithm used in a FIPS approved mode of operation? FIPS 140-2 Annex A will have to be updated, when P1619 becomes a standard, anyway. There are more serious issues with key derivation: the lack of security proofs with simple procedures - or the cost of complex key derivation; the cost of the key re-scheduling with changing keys. -Laszlo
> -------- Original Message -------- > Subject: FIPS requirements (was Re: Can LRW be optimized for multiple > sector keys?) > From: Robert Sussland <[EMAIL PROTECTED]> > Date: Mon, January 16, 2006 7:08 pm > To: stds-p1619@LISTSERV.IEEE.ORG > Cc: Mart_Sõmermaa <[EMAIL PROTECTED]> > > When discussing key derivation functions, it's important to note that > the resulting standard should be able to pass FIPS 140-2 > certification, as this is a requirement for government customers, as > well as many private sector customers. > > Mart's proposal, or any KDF proposal, will not pass FIPS PUB 140-2, > because in that standard: > > 1) A KDF may only be used as part of an asymmetric key establishment > protocol, and in that case it must be a NIST KDF, OR > > 2) The key may be derived in accordance with FIPS PUB 171 -- which no > one here wants to do, as this is a very prescriptive standard, OR > > 3) The key must be either generated from a NIST approved PRNG, or > generated from another FIPS module and then loaded into encryption > engine. > > Therefore, whatever KDFs are being considered for deriving the > various key components, I would leave them out of the standard, which > would allow FIPS 140-2 compliant implementations as well as vendor > specific implementations that do not need to be certified. > > Thanks, > Robert Sussland > > On Jan 16, 2006, at 6:00 AM, Mart Sõmermaa wrote: > > > Suppose we have a key derivation function f, that, given a global > > key GK and sector index i, generates a unique sector key K_i > > f(GK, i) = K_i > > that will be used to key e.g. LRW-AES. > > > > In this case, LRW key scope is only a single sector (generally 32 > > blocks). Hence, the table based optimisation for multiplication in > > GF(2^128) do not work -- multiplication table (as described in LRW > > draft section 5.1) scope is also only 32 blocks. Also, the tweak > > increment optimisation (ibid. 5.2.1) is useless for the same reason. > > > > Are there ways to optimize multiplication in GF(2^128) even when > > key scope is a single sector? > > > > It has to be noted, that XEX as specified in > > http://grouper.ieee.org/groups/1619/email/msg00610.html does not > > suffer these drawbacks and it seems that XEX is considerably more > > efficient than LRW in multiple key mode.
