Re: Question on Diffie-Hellman and key derivation

Thanks Ryan.

How stable is this model ? There's a lot here which isn't yet described in
the specification. I know there were discussions earlier in the year around
a secretAgreement method. Was it decided to stay with deriveKey or is this
still open ?

One more question below ...


On Mon, Dec 2, 2013 at 2:40 PM, Ryan Sleevi <sleevi@google.com> wrote:

>
>
>
> On Mon, Dec 2, 2013 at 2:36 PM, Mark Watson <watsonm@netflix.com> wrote:
>
>> Thanks Ryan.
>>
>> To check I've understood correctly, the answer to my question is actually
>> "both". For (a), to get a Key object that represents the raw shared secret
>> and can be used to further derive other keys, I specify the key derivation
>> algorithm (e.g. HKDF-CTR) as the derivedKeyType and then use deriveKey
>> again with that Key to get actual encrypt/decrypt/sign/verify algorithm
>> keys. To get a usable key directly, (b), I just specify the algorithm I
>> want and the first n bits of the shared secret are used.
>>
>> ...Mark
>>
>>
> I guess I make a distinction of "raw" key in the case of (a), since
> 'technically' the key is tagged as an HKDF-CTR key (eg: as the Ki input).
> You couldn't deriveKey to get an HKDF-CTR key, and then feed that in to a
> different deriveKey algorithm (eg: DH).
>
> But other than that slight nit, yes, correct.
>
>
>>
>> On Mon, Dec 2, 2013 at 2:28 PM, Ryan Sleevi <sleevi@google.com> wrote:
>>
>>>
>>>
>>>
>>> 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.
>>>
>>

Presumably you can specify the label and context in this second deriveKey
call i.e.:

deriveKey({name: "HKDF-CTR",  hash: { name: "SHA-256" }, label: ...,
context: ...}, hkdfKey, { name: "AES-GCM", length: 128})

Can you really also or instead specify them in the first call which creates
the Key ?

...Mark



>
>>> 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
>>>>
>>>>
>>>>
>>>
>>>
>>
>