Re: I want to have unsafe key exchange.

On Thu, Jun 14, 2012 at 12:50 PM, David Dahl <ddahl@mozilla.com> wrote:
>
> Initially, I think this was not a use case that was in mind for the API. However, we have discussed a few operations where this would be required to support specific protocols. I think in most cases, we would not want developers using this kind of 'the footgun is loaded' operation.

I think there will be many uses where it is necessary, so I hope that
the spec will require implementers to provide it. If we want to guide
developers toward safe patterns (and we do), then making something
optional in the spec, and thus inconsistent in the implementations, is
probably not a great way to accomplish that. Providing a safe and
always-available alternative way to do that thing which is
conceptually simple and well-documented sounds like the best tool we
have for that.

> 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 don't really understand the ideas of wrapping, persistence, ID'ing
in this context. (Not that I haven't tried! I believe I had read all
the minutes and mailing list messages on the subject.)

But it sounds rather unlike what I want.

What I'm asking for is the ability for JS code to invent some bytes in
any that it wants -- in ways that we today can't predict -- and then
use those bytes as a private key or as a symmetric key. Possible ways
it might generate such bytes include using some not-yet-invented KDF
based on user input (e.g. an interactive graphical application in
which the user selects photographs out of a set of photographs), and a
remote protocol involving one or more remote nodes that it
communicates with over the network to compute some sort of
not-yet-invented key agreement scheme or secure multiparty
computation.

Likewise, I'm asking for the ability for JS to (at least for keys
which have not been explicitly marked as "no unsafe key exchange
allowed"), read the bytes of the key so that it can transmit those
bytes to the user or to a remote party in some way that we haven't yet
invented.

> Do you have a use case written down for this kind of operation?

Not exactly. I have a ton of ideas and rambling notes here and
there... ;-) It's a little bit difficult to write down, because part
of the driving motivation for me is that I want to make it possible
for future authors of JS code to invent new protocols. I can't write
down all those as-yet-uninvented protocols, although I can certainly
write down a few. ;-)

Let me try to come up with some concrete use case real quick... How
about: implement ZRTP ¹  in 100% pure Javascript, deployable in
node.js, content JS, or chrome JS.

That's just the first random thing off the top of my head.

¹ https://en.wikipedia.org/wiki/ZRTP

Regards,

Zooko Wilcox-O'Hearn

Founder, CEO, and Customer Support Rep -- Least Authority Enterprises

https://leastauthority.com

Received on Thursday, 14 June 2012 20:18:41 UTC