Re: I want to have unsafe key exchange.

On Thu, Jun 14, 2012 at 11:10 AM, David Dahl <ddahl@mozilla.com> wrote:

> ----- Original Message -----
> > From: "Ryan Sleevi" <sleevi@google.com>
> > To: "David Dahl" <ddahl@mozilla.com>
> > Cc: "Zooko Wilcox-OHearn" <zooko@leastauthority.com>,
> public-webcrypto@w3.org
> > Sent: Thursday, June 14, 2012 11:59:47 AM
> > Subject: Re: I want to have unsafe key exchange.
> >
>
> > > As far as symmetric keys are concerned, I have been thinking we
> > > would spec
> > > out a wrapped key object, with the unwrapping happening out of the
> > > content
> > > JS scope. With a compelling use-case I can see an API that allows
> > > raw key
> > > material to be generated that is perhaps not persisted and not
> > > given any
> > > kind of ID. Would that satisfy your usage?
> > >
> >
> > I think this is a MUST requirement. Otherwise, the use of a DHE
> > exchange to
> > negotiate some keying material seems... not at all useful.
> >
>
> Isn't DH dependent on a public value that is used to generate a shared
> session key? Why can't this be done in an API like (please pretend it is
> event-driven):
>
> // Alice
> var rndm = crypto.dh.generatePublicRandomNumber();
> sendPublicRandomToBob(rndm);
>
> // Bob
> var recRndm = pollServerForPublicValue();
> var sessionKeyID = crypto.dh.generateSessionKey(recRndm);
> var rndm = crypto.dh.generatePublicRandomNumber();
> sendPublicRandomToAlice(rndm);
>
> // Alice
> var recRndm = pollServerForPublicValue();
> var sessionKeyID = crypto.dh.generateSessionKey(recRndm);
>
> var messageToBob = crypto.dh.encrypt(sessionKeyID, "53kr3t m355ag3");
> sendMessageToBob(messageToBob);
>
> Perhaps this is a completely naive view of this protocol?
>

dh.encrypt is where it breaks down.

DH is a key agreement protocol, not an encryption protocol. That is, you
use DH exchanges to obtain a stream of bytes that act as a shared secret.
Depending on the exchange and algorithm chosen, there may be sufficient
bytes for 'client/receiver' and 'server/sender' keys (after all, you want
to keep the keys separate to avoid IV re-use), there might by bytes for a
symmetric key + mac key, or there might be bytes enough to bootstrap some
secondary protocol.

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.




>
> > Wrapped keys are only useful if you have a wrapping key. How do you
> > import/export the wrapping key? For exchange between peers? Between
> > browsers?
> >
>
> You can exchange JWKs as strings, then:
>
> arrBuffPubKey = JSON.parse(jwk);
>
> // now you can encrypt a message:
>
> var pkAPI = new crypto.pk();
>
> pkAPI.onEncryptFinished = function(aCipherMessage) {
>  // this returns ab arrayBuffer that has contents like:
>  { wrappedKey: 71251421526, iv: 1762152, cipherData:
> 619873836477286376527, etc... }
>
>  // We can push the array buffer via websockets to the server or call
> toJSON() to POST it, etc
> };
>
> pkAPI.encrypt(arrBuffPubKey, "s3cr3t m355ag3");
>
> Again, perhaps this is a bit naive. My crypto work experience is short.
> Nothing I am saying precludes additional APIs that open the apps up to more
> dangerous raw-key collection and usage. We could provide flags that allow
> it.


> I personally want to use a higher-level API that is safer. Of course,
> box/unbox is at too high of a level for my needs.
>
> Cheers,
>
> David
>