- From: Mitar <mmitar@gmail.com>
- Date: Thu, 28 Jan 2016 19:53:02 -0800
- To: Jim Schaad <ietf@augustcellars.com>
- Cc: public-webcrypto@w3.org
Hi! On Thu, Jan 28, 2016 at 2:16 PM, Jim Schaad <ietf@augustcellars.com> wrote: > Derive bits needs to be able to return the secret directly, otherwise one could not implement a KDF function which is not supported by the base spec - for example using the AES-CMAC that you seem to be supporting. If memory serves, there was discussion at one point of allowing a KDF function to be passed in. But it was never specified. Yes, I am OK with deriveBits giving directly the bits. But there could be some non-normative note saying that one should post-process those bits and not use them directly. > Derive key has a KDF algorithm that is applied to the raw shared secret in order to a better secret to be use, and to import that secret and return a key object. Hm, have I missed this KDF algorithm? Where it is defined? Where it is defined that deriveKey uses any KDF algorithm? I see only: > Let secret be the result of executing the derive bits operation specified by normalizedAlgorithm using key, algorithm and length. > Let result be the result of executing the import key operation specified by normalizedDerivedKeyAlgorithm using "raw" as format, secret as keyData, derivedKeyType as algorithm and using extractable and usages. So we get derive bits (without any hashing). And then we import them as "raw" bits. Where is KDF here? Mitar -- http://mitar.tnode.com/ https://twitter.com/mitar_m
Received on Friday, 29 January 2016 03:53:37 UTC