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

[Bug 25721] extractable keys should be disabled by default

From: <bugzilla@jessica.w3.org>
Date: Thu, 15 May 2014 20:36:26 +0000
To: public-webcrypto@w3.org
Message-ID: <bug-25721-7213-sGBfbo3kNN@http.www.w3.org/Bugs/Public/>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25721

elijah@riseup.net changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|FIXED                       |---

--- Comment #4 from elijah@riseup.net ---
> As noted in the security considerations, ANY code executing in the context
> of the origin can fully compromise WebCrypto, as they can compromise any
> other Javascript. I can appreciate your sensitivity towards privacy, but
> this is not how Javascript works.

This statement is entirely misleading for two reasons:

(1) There is HUGE DIFFERENCE between modifying javascript to capture the
cleartext result of an encryption process and being able to capture the keys,
which gives an attacker access to all prior and future communication that used
that key. The attack surface of the former is a narrow window of time,
requiring targeted injection of malicious javascript, where as the attack
surface of the latter is as big as a freaking planet.

(2) the "way javascript works" is in flux. There are many interesting projects
to separate the javascript app from data storage, using CORS or PostMessage,
and also to verify the integrity of the js code (although this is less
advanced). Code signing for JS will come eventually, although sadly not with
WebCrypto.

> Consider the Decrypt case - there is zero added privacy by requiring the user
> to be *prompted* to make the key extractable, as the origin has full access
> to all plaintext that results after the ciphertext

Not true, see #1.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
Received on Thursday, 15 May 2014 20:36:28 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:17:22 UTC