Re: Question on Diffie-Hellman and key derivation

On Tue, Dec 3, 2013 at 12:24 PM, Mark Watson <watsonm@netflix.com> wrote:

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

The issue was on deriveBits, which Vijay and Richard agreed as resolved
during our Shenzhen F2F. Key derivation in crypto APIs that attempt to keep
key material opaque is always one of the roughest edges because so many
schemes are so different or have such different requirements.


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

Yeah, this is something that needs to be figured out (eg: if there's a new
params object for key derivation).

An alternative scheme would be to support 'generic' raw key objects, with
the only specifier being a 'length', and then feed those into derivation
schemes. I'm not sure such a solution would actually work (eg: I don't know
if it's a model that can be consistently implemented with > 1 crypto API),
but it's a thought.

I'm very much with you that I want a syntax that yields a single Ki for
multiple Kderived, with the second (and third and subsequent) deriveKey
calls specifying how to get the different Kderiveds. That means that the
second deriveKey should be able to specify the label/context. This was just
the off-the-cuff speculation of how it would/could look.





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