Hi Robert,
thanks for the info and your comments. IMO, the high-order bit from
all of this discussion is that the NIST specs do not cover the
encrypted storage case, and that the working group ought to be
providing input to them on what crypto methods are needed.
A few comments below:
On Jan 18, 2006, at 3:52 PM, Robert Sussland wrote:
David,
Does FIPS-140-2 actually put this restriction on a KDF?
Yes, perhaps this may help explain the matter:
FIPS 140-2 is a prescriptive standard; vendors are not allowed to
mix and match elements of security functions, and no KDF is by
itself an approved security function. A KDF can therefore only be
used as a component to an existing allowed security function.
For example, currently FIPS modules can establish keys with TLS.
TLS uses a KDF, so the TLS-KDF may be used, but only in the context
of TLS. The draft you cited is a KDF used in within draft-SP800-56,
as well as in ANSI X9.63. The acceptability of the KDF depends on
which key establishment protocol it is used in.
To see a list of which key establishment protocols are allowed,
look at Annex D. You'll find that effectively NIST allows only
asymmetric key establishment.
A short question - are you referring to the September, 2005 draft of
Annex D? That draft allows the "AES Key Wrap", which is not a KDF of
course, but is a symmetric key establishment method.
Within the framework of an allowed asymmetric key establishment,
multitudes of KDFs may be used, but not in LRW-AES. I'm assuming
here that we will not create a TLS style key agreement scheme in
which we generate keys from a KDF. Outside of asymmetric crypto,
you have to stick to generating keys from a PRNG or having the keys
loaded externally into your module.
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.
No, Section 3.1 says that the values may be established with a
mechanism out of scope of the draft, in which case shared info
values must be provided by that mechanism. Section 3.1 does not
discuss whether the parent key establishment framework is or is not
allowed in FIPS 140-2.
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.
Yes, I agree. However, I view the current LRW-AES document as the
definition of an encryption mode. It is unusual to mandate any type
of key management in an encryption mode definition -- even if the
mandate consists of a list of options. It's fine to have a
discussion of threats and advantages relating to keys, but to
specify key derivation algorithms is dangerous. First, you can't
forsee how this mode will be used, if successful, so there is a
risk of hamstringing vendors in the future. Also, suppose a
vulnerability is announced in a KDF -- does this kill AES-LRW?
Tomorrow a hot KDF is announced, and vendors want to use it instead
of what is specified. In general requirements on the keys should be
stated in a mode document, not mechanisms of achieving those
requirements. Optimizations to mechanisms, although valuable, are
rarely robust.
Note that NIST has already issued SP-800-57 Part 1, General Key
Management Guidance. A discussion of how those requirements apply
when using LRW-AES in a stored data environment would be an
important document to have, but not incorporated into the
specification of the encryption algorithm.
I certainly agree that the mode definition needs to be distinct from
the key management definition. But a key management standard would
be quite useful as well. Key management is more needed for GCM or
CCM than for LRW (or any other 'wide block' cipher mode). Matt
Ball's example of a case in which a customer enters a single key into
multiple storage systems is a great motivator for a key management
layer - otherwise, how could a storage system be sure that it is
enforcing the requirement for the non-repetition of an input nonce
for those modes?
David
Thanks,
Robert
