Re:Show HN: CryptoNote is an open source, encrypted, one tim...
by daeken on Friday June 07, 2013 @04:55PM
(#5841799)
Client-side crypto in JS has value if and only if the following conditions are all met:
1) The application receives no HTML, CSS, Javascript, or code interpreted by plugins from a server in the same context (e.g. not an iframe) as the crypto code.
2) All assets that are run in the context of the crypto code are fixed and signed. No unsigned javascript code (generated at runtime, passed from a server or input to the app, whatever) is permitted to run in any way in that context.
3) The code as signed is completely transparent. It must be possible to audit the code as it would be run, and be able to 'quarantine' updates.
Without all of these things being met, client-side crypto in the browser is completely untrustable. These conditions have never been met.
There's a spectrum between "unencrypted webpage loaded over cafe WiFi" and "locally compiled open-source application". You don't always need the latter.
EDIT: Say you're using a web app that encrypts your data on the client. All the executable assets (html, js, css) are static and hosted on a CDN over HTTPS. The app stores your encrypted data to another server. Even if that server is compromised, it's still impossible to access your data without also compromising the CDN (assuming a correct implementation of the crypto and no XSS vulnerabilities, of course).
EDIT2: It would be interesting if you could sign a bundle of static assets that the browser could verify. Maybe as part of the HTML5 app cache. Like a lightweight version of a Chrome app. Add on a restrictive Content Security Policy and it sounds pretty good to me.