Re: Question on Diffie-Hellman and key derivation

On Mon, Dec 2, 2013 at 2:06 PM, Mark Watson <watsonm@netflix.com> wrote:

> All,
>
> I have a rather basic question about how Diffie-Hellman is supposed to
> work in the current draft. I scoured the archives, and whilst there is
> plenty of discussion of and around this issue, nowhere does there seem to
> be an answer.
>
> The question is, when executing the second DH step, by feeding in the peer
> public value to deriveKey, what is the output ? Is it:
> (a) a Key object that represents the raw shared secret bits that are the
> output of the DH operation, or
> (b) a Key object that represents a usable key for some other WebCrypto
> algorithm (say AES-GCM)
>

Depends on whether you call deriveKey or deriveBits

deriveKey({name: "DH", public: ...}, dhPrivateKey) == error (no derived key
type specified, cannot be inferred)
deriveKey({name: "DH", public: ...}, dhPrivateKey, { name: "AES-GCM",
length: 128}) == first 128-bits of s (the shared secret) as a key
deriveBits({name: "DH", public: ...}, dhPrivateKey, 128) == first 128 bits
of s
deriveBits({name: "DH", public: ...}, dhPrivateKey, 2048) == error if
len(s) < 2048 bits, otherwise, first 2048 bits

[Mod the outstanding issue about bits/bytes inconsistency]

If you want to derive 2 keys (eg: a decryption and encryption key among two
parties), you'd need to deriveBits, not deriveKey.

This is *BY DESIGN*, and part of the *very long* discussions about the
complexities about trying to specify different 'key slicing' schemes.


>
> If (a), what should be specified as the derivedKeyType parameter to
> deriveKey ? null ?
>
> If (b), where are the key derivation algorithm and its parameters
> specified that derive the key from the raw shared secret bits ?
>

It's the actual, raw bits of S.

If you want to further feed into a KDF, like HDKF-CTR

deriveKey({name: "DH", public: ...}, dhPrivateKey, { name: "HKDF-CTR",
hash: { name: "SHA-256" }, label: ..., context: ... }) == a Key object that
can be used with deriveKey / deriveBits, such that Ki (as defined in
Section 5.1 of SP 800-108)

You could then
deriveKey({name: "HKDF-CTR", ...}, hkdfKey, { name: "AES-GCM", length:
128}) to get the different keys by varying context.

This of course highlights one bit of ambiguity. SP800-108 defines multiple
ways of recognized KDFs. In the case of CMAC (not listed ATM), the length
of Ki can be inferred by the underlying block function, but in the case of
HKDF-CTR, because HMAC accomodates variable length keys, it's unclear how
many bits of "s" (the shared secret) should be used as Ki.

These are the kind of bugs that crop up when working through specifying,
but mod the HKDF key length issue, that's how it "should" work


>
> ...Mark
>
>
>