W3C home > Mailing lists > Public > public-webcrypto@w3.org > June 2012

Re: I want to have unsafe key exchange.

From: Wan-Teh Chang <wtc@google.com>
Date: Mon, 18 Jun 2012 11:34:04 -0700
Message-ID: <CALTJjxEXZt+NB4nrCxLvq3QPxPZJqSVq1GH1bhsrTZGSU_-mTQ@mail.gmail.com>
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.)

Received on Monday, 18 June 2012 18:34:41 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:17:10 UTC