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

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.


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

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?

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?