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

Re: ECC vs RSA, and Similar Conflicts

From: Eric Rescorla <ekr@rtfm.com>
Date: Thu, 10 May 2012 08:11:49 -0700
Message-ID: <CABcZeBPRw=nt59T-E3ZHA4gh_ZmzQzsfzeL3Mh6CORFDLqiwkQ@mail.gmail.com>
To: Jarred Nicholls <jarred@webkit.org>
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 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.

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.

-Ekr
Received on Thursday, 10 May 2012 15:13:01 UTC

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