Re: Define how keys are derived from secret values for deriveKey

On Tue, Feb 25, 2014 at 3:33 PM, Mark Watson <watsonm@netflix.com> wrote:

>
>
>
> On Tue, Feb 25, 2014 at 12:47 PM, Ryan Sleevi <sleevi@google.com> wrote:
>
>>
>>
>>
>> On Tue, Feb 25, 2014 at 12:01 PM, Mark Watson <watsonm@netflix.com>wrote:
>>
>>> https://www.w3.org/Bugs/Public/show_bug.cgi?id=24811
>>>
>>> The deriveKey operation derives a key targeted at a specified algorithm. Both ECDH and DH algorithms output a Secret Value.
>>>
>>> It is not yet specified how to map from the Secret Value to a key for the specified target algorithm.
>>>
>>> It seems intuitive to use the "raw" import format for the target algorithm with the Secret Value as the raw input. If we do this we must define how to provide the length of the key and how to convert the secret value to that length. Presently, raw import for symmetric keys e.g. AES-GCM derives the key length from the provided data and fails if the provided data is not one of the supported lengths.
>>>
>>> It seems valuable to be able to specify the length of the required key independently from the length of the Secret Value.
>>>
>>>
>> I'm not sure I follow what you're proposing here regarding separate
>> lengths.
>>
>
> The length of the secret value is whatever the (EC)DH outputs. The length
> of the AES key you want could be 128, 192 or 256.
>
> We can either say the AES key length is some function of the secret value
> length, or we could allow the AES key length to be specified directly.
>
>
>>
>>>  So, one possibility is to allow the length of the symmetric key to be specified as an input to the import operation and have that operation define the mapping from arbitrary length raw value to a key of the requested length. The deriveKey operations can then refer directly to the "raw" import operations for the derived key algorithm.
>>>
>>>  ...Mark
>>>
>>
>> Yes, I agree that for the case of deriving symmetric keys - whether
>> "directly" (eg: by treating the DH Phase 2 output as a direct input to a
>> key) or "indirectly" (eg: by treating the DH Phase 2 output as an input
>> into another KDF, like HDKF/Concat) - it's necessary to specify additional
>> parameters.
>>
>> You suggest that it's "one possibility", but I'm curious if you see there
>> being any other possibilities.
>>
>
> Not really - I just said "one possibility" to emphasize the tentative
> nature of the proposal. But what you suggest below is different from what I
> suggested ...
>

I don't know if it's a matter of not having coffee handy, but I'm at a loss
still for parsing some of this email, so I'm again going to try to get
clarifications.


>
>
>> Import:
>>   - If length is present
>>     - If length is 'consistent' with the import data - success
>>     - If length is 'inconsistent' with the import data - failure
>>  - If length is absent
>>   - ?? Fail? Or derived from import data? How is this similar to or
>> different than the JWK import cases where alg is optional?
>>
>
> For "pure" import, the length of the data itself is an explicit indication
> of the required key length. It can't be absent. We do not have a separate
> AesImportParams dictionary and we don't need one (yet - see below).
>

> It's different from JWK "alg", because alg is optional and because we *do*have a place in the method parameters to specify the information that might
> be in the alg field. Thus we have to specify the requirement for
> consistency.
>
>
>> Derive:
>>   - If length is present
>>     - If length is less than the maximum output of the key derivation
>> step (if any) - create a key from the first (length) bits and feed to
>> import("raw")
>>    - If length is greater than the maximum output of the key derivation
>> step - fail
>>  - If length is absent
>>    - Fail
>>
>> Have I missed any other edge conditions?
>>
>
> No. I think what you've written is the right approach, but it's a little
> tricky to see how we implement this in the specification.
>
> The derive logic above could be part of the (EC)DH derive operation. It
> has the truncation step which happens before the "raw" AES import
> operation. The truncation step needs access to a length field. The
> intuitive place to specify this length is in the deriveKeyType method
> parameter. e.g.:
>
> p = deriveKey( { name: "DH", public: PV }, dhPrivateKey, { name:
> "AES-GCM", *length: 256* }, false, [ "encrypt", "decrypt" ] )
>
> However, what is the subclass of the derivedKeyType field ? Presumably it
> is something like an AesImportParams.
>
> So, then, we have an operation which is part of the (EC)DH "derive"
> procedures (the truncation) which needs information from an AES-specific
> structure. Awkward.
>

To be clear, my understanding of your proposal is that we add an
AesImportParams, and that length is specified. That's why I sought
clarification, above, as to what to do. Is "length" optional (implied from
context) or is it required (even when it can be inferred?) This is EXACTLY
the same conversation we had regarding JWK - a parameter which can be
inferred for some operations (AES 'raw' import, JWK with an 'alg'
parameter) but not for other operations (AES 'derived' import, JWK without
an 'alg' parameter).

Please explain why you find this awkward, however, as you didn't really
qualify it. derivedKeyType is specifying the "shape" of the key to be
derived. The length is part of that shape. Arguably, however, so is the
algorithm. For example, it's entirely possible (as discussed on past calls)
that things like parity bits might enter the equation if talking 3DES keys
- they're both fundamentally shapes of what the derived key is going to
look like.


>
> We could resolve this by putting the truncation operation into the "raw"
> AES import procedures and adding the length as an input to these. If we
> wanted true import to work as you have specified, then we'd need those
> procedures to have two modes "strict length" mode, in which a length
> mis-match is an error and "non-strict length" mode in which truncation can
> be performed. This could be a boolean input parameter which is "strict"
> when the "raw" input procedures are called from importKey and "non-strict"
> when they are called from the derive operation of another algorithm.
>
> Any better ideas ?
>
> ...Mark
>
>
I do not parse this at all, but it sounds overly complex and very different
than what I was proposing - and how we handle other parameters of a similar
type (eg: JWK)

I don't see where the issue is with keeping truncation as part of key
derivation. That is, it has always been my understanding that a deriveKey()
operation is comprised of

[1. run the KDF] + [2. do some special steps _within the 'kdf' alg] + [3.
import a key with the result]

The truncation step is [2]. Parity bits would be [2]. Any other 'shaping'
would be [2].

If the question is where do you specify the parameters for [2], I still
believe that derivedKeyType is the right place.