Robert,
On Jan 16, 2006, at 4:08 PM, Robert Sussland wrote:
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
Does FIPS-140-2 actually put this restriction on a KDF? That's
certainly an unneeded restriction, and also it is at odds with
Section 3.1 of http://www.ietf.org/internet-drafts/draft-dang-
nistkdf-00.txt, "(Key Derivation from) Secret Values Established out
of band". So even if the current FIPS-140 docs have this
restriction, it is clearly not the intended direction of NIST.
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.
Well, it's not necessary to leave KDFs out of the specs in order to
allow implementations to be FIPS-140 conformant. It is sufficient to
not have a mandatory-to-use KDF that is not FIPS-140 conformant. The
spec could mandate a KDF that didn't conform to FIPS-140, and it
would still be possible to get a FIPS-140 validation, which would
need to reference a security policy describing how to operate the
cryptomodule in a manner that didn't use the non-coformant KDF.
David
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.
