Subject: Re: [Cfrg] Work on KDF Internet-Draft

From: "Steven M. Bellovin" <[email-masked]>
Date: Mon, 23 Sep 2002 10:35:13 -0400

In message <003901c26305$261b60f0$6900a8c0@p1038mobile>, "Anton Stiglic" writes
:
>
>I would like to mention that there is a skunwork group working at
>writing an Internet-Draft that proposes a key derivation function (KDF).
>We believe that a standard for a key derivation function is useful, 
>given the fact that almost every new project/design seems to invent
>it's own KDF.  See the bottom of this e-mail for a list of different
>KDF that have been proposed in the past.
>Ideally, we would like to propose a construct who's security can 
>be backed up by some theoretical results, but also we would like
>it to be backwards compatible with different KDF that have already
>been proposed (most of which have been designed in an ad-hoc way).
>

Also see Uri Blumenthal's draft (draft-blumenthal-keygen-03.txt).

		--Steve Bellovin, http://www.research.att.com/~smb (me)
		http://www.wilyhacker.com ("Firewalls" book)

_______________________________________________
Cfrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/cfrg

---

From: "Daniel Brown" <[email-masked]>
Date: Mon, 23 Sep 2002 16:28:58 -0400

Anton and Bodo:

I'd like to mention that the published standards
ANSI X9.63 and SEC1 also specify a KDF. It is the
same as KDF2 in the draft of IEEE P1363a,
except with regards to the hash function allowed.

ANSI X9.63 says that an ANSI approved
hash function may be used.  The new hash
functions SHA-256, SHA-384 and SHA-512
should soon be ANSI approved, I expect.

SEC1 mentions that support of "SHA-2" is planned.
(The next revision should allow SHA256, SHA384
and SHA512).

I'm also aware of two KDFs defined in the current
draft of ANSI X9.42, but I have not looked closely
at these.

Regarding TLS, since KDF2 supports hashes larger
than SHA1, specifically SHA256, SHA384 and SHA512,
yet another approach to TLS is to use KDF2 with
hash functions roughly matching the EC security strength.
(The output length of KDF2 is adjustable, but since TLS puts
it into a PRF, using the output length of the hash
used seems a good approach.) To preserve
backwards compatibility with existing
implementations, KDF1 can be used for
the lower security levels of EC parameters, such as
80-bit security (ECs over 192-bit prime and 163-bit binary
curves). The use of KDF2 has the advantage that it will
be compatible with IEEE P1363a, ANSI X9.63 and the
revision of SEC1.  Once the key is derived via the KDF,
the usual TLS-PRF can be applied, so an
IEEE P1363/ANSI X9.63 implementation of ECDH can
be dropped into to a TLS implementation fairly easily.
(By the way, RFC 3278 uses KDF2 in ECDH.)

     - Dan