- From: Ryan Sleevi <sleevi@google.com>
- Date: Fri, 26 Jul 2013 10:22:32 -0700
- To: Alessandro Di Federico <alessandro.difederico@mail.polimi.it>
- Cc: "public-webcrypto-comments@w3.org" <public-webcrypto-comments@w3.org>, Michele Beretta <michele3.beretta@mail.polimi.it>
On Fri, Jul 26, 2013 at 5:50 AM, Alessandro Di Federico <alessandro.difederico@mail.polimi.it> wrote: > Hello, we'd like to have some clarifications about the key derivation > process (partly related to the issues 35 [1] and 36 [2]): > > * What is the output of deriveKey supposed to be? I know you can choose > to generate a key with the derivedKeyType parameter (e.g. AES-CBC), > but is it possible to have the raw output of the operation, i.e. > exponentiation for classic DH and multiplication for ECDH? Do you > plan to enforce some kind of hash pass before returning the key? > In our algorithms (FHMQV [3] and Boudot's solution for SMP [4]) we > use EC multiplication quite frequently and being able to have a native > implementation would be very useful. See ISSUE-84 http://lists.w3.org/Archives/Public/public-webcrypto/2013May/0106.html and the continued discussion on http://lists.w3.org/Archives/Public/public-webcrypto/2013Jul/0069.html Vijay proposes a deriveBits for handling KDF output. However, as pointed out in the second thread, specifically http://lists.w3.org/Archives/Public/public-webcrypto/2013Jul/0112.html , there's an issue with handling situations where you want the 'raw output' (eg: Z, the agreed secret). Several solutions are discussed there, including just punting the issue. > * Is it always possible to export a private/symmetric key? I'm not sure I understand this. Whether or not you can extract a key is covered by the extractable attribute. If the caller requests an extractable key, and the underlying implementation cannot satisfy that request (eg: cannot make the key extractable), then it should fail the operation. So if you wish to export it, requesting it be exportable/extractable is sufficient. Conversely, setting extractable = false is **not** a guarantee of some secure element being in play. It just means JS cannot access the key. > > Alessandro Di Federico > > [1] https://www.w3.org/2012/webcrypto/track/issues/35 > [2] https://www.w3.org/2012/webcrypto/track/issues/36 > [3] http://eprint.iacr.org/2009/408.pdf > [4] http://www.win.tue.nl/~berry/papers/dam.pdf > >
Received on Friday, 26 July 2013 17:22:59 UTC