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.
