Re: ECC vs RSA, and Similar Conflicts

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
>