RE: I want to have unsafe key exchange.

I'd like to advocate for not requiring the raw shared secret to be accessible to apps.

Many crypto modules (often for FIPS and other certification purposes) only expose the key agreement primitive (i.e. DH operation + a KDF) and do not expose a raw DH primitive. For the specific case of ZRTP, this would appear to be enough - ZRTP appears to be doing an SP800-56A key agreement (i.e. DH + SP 800-56A KDF) followed by another KDF (i.e. SP 800-108 KDF). This is achievable as long as we provide a KDF primitive. I do agree we must provide a facility for importing raw keys if we want to support any form of DH (as others have noted).

I realize raw DH is useful in various places; but it's arguable that it is similar to mod-exp - a math-level primitive which is not essential to a crypto-level API.

-----Original Message-----
From: Eric Rescorla [mailto:ekr@rtfm.com] 
Sent: Monday, June 18, 2012 12:41 PM
To: Wan-Teh Chang
Cc: Ryan Sleevi; David Dahl; Zooko Wilcox-OHearn; public-webcrypto@w3.org
Subject: Re: I want to have unsafe key exchange.

On Mon, Jun 18, 2012 at 11:34 AM, Wan-Teh Chang <wtc@google.com> wrote:
> 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.)

I don't believe that this can be done without effectively allowing the application to extract the secret input if it chooses to.

I.e., this is a cut point between two models of key isolation:

(1) reduce application screwups by making it hard to access the key
(2) protect against malicious applications accessing the key.


-Ekr

Received on Saturday, 30 June 2012 07:16:42 UTC