4492 references the substantial KDFs used for any keyexchange in TLS, consistent with my "somewhere else", but as you quoted specifies identity=trivial derivation directly on the ECDH agreement. The comment and code in speed.c indicate a draft spec to conditionally do SHA1 directly on the agreement, and that's ambiguously not in 4492.
_____ From: [email protected] [mailto:[email protected]] On Behalf Of Matt Caswell ([email protected]) Sent: Tuesday, 18 December, 2012 02:48 To: [email protected] Subject: Re: Need help in loading private key for ECDSA On 17 December 2012 23:06, Dave Thompson <[email protected]> wrote: > aout = ECDH_compute_key(abuf, alen, EC_KEY_get0_public_key(ecdh2), > ecdh, KDF1_SHA1); What is KDF1_SHA1? If it's copied from ec/ecdhtest.c or apps/speed.c, that's designed to use SHA1; if you want something else, change it. I'm not sure why it's even there; the comment in speed.c says it was in a tls-ecc draft, but it is NOT in 4492. I don't know of any other ECDH (or DH) applications that apply a nontrivial KDF directly to the agreement; if they do key derivation, it's somewhere else. Well it is kind of in 4492: "All ECDH calculations (including parameter and key generation as well as the shared secret calculation) are performed according to [6] using the ECKAS-DH1 scheme with the identity map as key derivation function (KDF)..." ...followed by... "(Note that this use of the identity KDF is a technicality. The complete picture is that ECDH is employed with a non-trivial KDF because TLS does not directly use the premaster secret for anything other than for computing the master secret. As of TLS 1.0 [2] and 1.1 [3], this means that the MD5- and SHA-1-based TLS PRF serves as a KDF;..." Matt
