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

Re: ECC vs RSA, and Similar Conflicts

From: Jarred Nicholls <jarred@webkit.org>
Date: Thu, 10 May 2012 11:31:21 -0400
Message-ID: <CANufG2ND9MV=R-R9-YZSKxC8oNEBAP4XUnEVxuX1hrhdDQ+6Dg@mail.gmail.com>
To: Eric Rescorla <ekr@rtfm.com>
Cc: David Dahl <ddahl@mozilla.com>, "Richard L. Barnes" <rbarnes@bbn.com>, Nadim <nadim@nadim.cc>, public-webcrypto@w3.org, Cullen Jennings <fluffy@cisco.com>
On Thu, May 10, 2012 at 11:11 AM, Eric Rescorla <ekr@rtfm.com> wrote:

> On Thu, May 10, 2012 at 7:56 AM, Jarred Nicholls <jarred@webkit.org>
> wrote:
> > Where the private key is directly accessible by script loaded from
> > same-origin?
> >
> > Compromised server injects hostile script into a page response, grabs the
> > private key, posts it to a foreign server, and now the private key has
> been
> > stolen and used to decrypt any data between the server and its clients
> > out-of-band.
>
> Yes, this is the case people raise most often. I see a number of
> problems with this
> line of argument.
>
> To take the specific example of encrypted data where the key pair used to
> decrypt it is stored in the browser, it has bad interactions with:
>
> (a) Any time the user somehow wipes his client-side state. I don't have
> data
> on this to hand, but last time I looked this happened quite often.
> (b) Any time the user switches browsers, with sync thus becoming a critical
> path item opening a whole new can of worms.


> Imagine how I would build an encrypted version of gmail with this design,
> for instance.
>

Right.  Not to mention that the same argument can be made regarding
stealing the unencrypted data and posting it to a foreign assailant, where
obtaining the key means little to nothing when it is just a means to an
end, i.e. stealing a particular client's encrypted data.  Whether this is a
use case to solve or not is to be determined, officially.  Keeping things
truly secured on the client would probably amount to a much wider scope to
the API, e.g. a combination of signed JS code and a secured JS execution
context.


>
> For both these reasons, it seems likely that any Web app that uses this
> API will
> want to favor designs that don't require long-term browser-side
> persistence of
> keys, or at least can auto-refresh them, the way that BrowserId does now.
> Of course, for any interactive protocol, you should be using crypto
> that provides
> PFS, so this kind of key theft is an issue would have much less salience.
>

Most vendors have secure sync protocols already that would be fairly easy
to enhance to sync stored keys.  While it is a consideration in terms of
adoption and practical usage, I believe this is a problem that's out of
scope of the API and WG.


>
> -Ekr
>
Received on Thursday, 10 May 2012 15:32:18 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 16 May 2012 18:59:57 GMT