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

> 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 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:01:01 UTC