5 ms·
Is browser-based crypto ever feasible? I'm surprised you're entertaining the idea. (Edit: Sorry. I misread. I was only hoping to learn something new.) It seem
by sillysaurus 14y ago
Is browser-based crypto ever feasible?
I'm surprised you're entertaining the idea. (Edit: Sorry. I misread. I was only hoping to learn something new.)
It seems like at a minimum users would need to disable all browser extensions before uploading their content. That doesn't seem realistic, so browser-based crypto seems dubious.
- tptacek 14y agoI'm not entertaining the idea! I'm not interested in picking apart Mega, but I am interested in how people choose crypto primitives and what libraries they have available to them. Don't do crypto in browser Javascript!
- blake8086 14y agoWhat's wrong with the core idea of "more secure server validates less secure server's JS before running it"?
- jiggy2011 14y agoIs the problem with the JS language itself, with certain JS runtimes or with just the idea of running a program inside a web browser to do crypto?
- STRML 14y agoThe problem is multifaceted; first, JS crypto is slow in most current implementations (but will get better with Typed Arrays). Second and more importantly, it is difficult to ensure total security on a page. While loading all assets from a single server using SSL helps quite a bit, there's really nothing stopping a malicious extension from getting in the way and stealing your passwords. Of course that's true of any website in general so the lesson is: be careful what extensions you install. Third, browser support is still garbage. Safari has major issues, Firefox is lacking support in critical places, and IE, don't bother. However the future is bright. With Typed Arrays & Web Workers running on all threads, you can expect 10+MB/s crypto in-browser very soon. That's slow by any other standard but potentially good enough for a browser. Hell, I'm pushing about 3.5MB/s on a MBA on securesha.re, which does 128-bit AES. Just for disclosure, I wrote securesha.re (and succumbed to a few of these problems while writing it).
- JoachimSchipper 14y ago> However the future is bright ... for attackers with some knowledge of side-channel attacks, which are almost impossible to block from Javascript.
- sillysaurus 14y agoIs the problem with the JS language itself? I don't know. I do know that other dynamic languages are trusted to perform crypto (e.g. Python). The fact that any dynamic language is trusted leads me to believe JS as a language may be fine. or with certain JS runtimes? Yes, each runtime must be analyzed by a crypto expert to uncover e.g. timing attack vulnerabilities, etc. or with just the idea of running a program inside a web browser to do crypto? Yes, implementing crypto within a webpage is a bad idea for many reasons. The first is that you must ultimately trust the browser itself, as well as its updater program. Second, you must trust every browser extension, since any extension can arbitrarily modify the page, and hence the javascript. (e.g. Reddit Enhancement Suite does this.) Since every extension can be updated at any time, you can't really trust any extension. Third, the javascript can be compromised in many other ways (e.g. XSS attack, etc). Fourth, crypto itself is extremely difficult to implement correctly, and it's easy to trick yourself into adding flaws while implementing it. For these and other reasons, browser-based crypto can't ever be trusted. Not yet, and not until the above concerns are no longer relevant.
- tptacek 14y agoWhen Python performs crypto operations, it isn't doing that while running alongside potentially hostile content-controlled code. The first thing everyone thinks when they read about browser JS being a hostile environment for crypto is, "LANGUAGE WAR!" But this issue has nothing at all to do with languages. If Python was the de-facto standard content-controlled browser programming language, we'd be saying "don't do crypto in browser Python".
- sillysaurus 14y agoThe question was "Can the design of any programming language ever affect the security of crypto code implemented correctly within it?" This question is extremely broad, and it requires envisioning future languages which haven't been invented yet, and looking for ways the design of the language itself might impact the security of crypto code implemented within it. That said, the question isn't the most important one. It was his third question which you and I both responded to.
- anonymouz 14y agoMore fundamentally then the reasons others have already stated is that the JavaScript is loaded from a server anyway. So you trust the server anyway, and hence may as well just do the encryption on the server.
- tptacek 14y agoYes. This is also why assurances that XSS bugs have been fixed aren't comforting. The problem isn't simply that attackers will find ways to corrupt the JS crypto code; the problem is that it is extremely difficult for end-users to verify that the crypto code they're running isn't bugged.
- STRML 14y agoWouldn't that be true of using any service handling sensitive information e.g. online banking?
- jiggy2011 14y agoThis is why internet banking sites use 2 factor auth.
- tedunangst 14y agoYour bank's website is most likely not encrypting your data with javascript.