- From: Wan-Teh Chang <wtc@google.com>
- Date: Mon, 18 Jun 2012 11:34:04 -0700
- To: Ryan Sleevi <sleevi@google.com>
- Cc: David Dahl <ddahl@mozilla.com>, Zooko Wilcox-OHearn <zooko@leastauthority.com>, public-webcrypto@w3.org
On Thu, Jun 14, 2012 at 11:21 AM, Ryan Sleevi <sleevi@google.com> wrote: > > That was sort of the point - the end result of a DH exchange is some shared > secret that both Alice and Bob know, but that Eve does not. How this shared > secret is used is up to the application, and may require access to the 'raw' > key bytes - eg: it may go into a second key expansion/key derivation > function if the original DH bytes are not of sufficient length to provide > for all of the necessary keys. Yes. This is an important design decision. One design is for the API to provide a few key derivation functions that take this raw shared secret as an input key handle and return the output key handles. Another design is to simply allow an application to export the raw shared secret and derive the keys itself. (This is what Zooko asked for.) These two designs aren't mutually exclusive. I think we should provide the commonly used key derivation functions to reduce application mistakes. But I find Zooko's challenge of implementing ZRTP very thought-provoking. Since the key derivation function of ZRTP doesn't seem to be a common one, I believe that a web browser will need to export the raw shared secret either in native code or in JavaScript. (I don't know of a native crypto API that allows a caller to provide an arbitrary key derivation function.) Wan-Teh
Received on Monday, 18 June 2012 18:34:41 UTC