5 ms·
So, forgive me for asking a dumb question. What would be a better approach here? I'm assuming that SHA1 doesn't cut it.
by jiggy2011 14y ago
So, forgive me for asking a dumb question. What would be a better approach here? I'm assuming that SHA1 doesn't cut it.
- sillysaurus 14y agoWhat would be a better approach? To not encrypt files via a browser using javascript. One reason this particular flaw happened was due to the need to secure all content loaded insecurely by index.html, for example.
- kevinpet 14y agoEncrypting files in the browser with javascript is a perfectly valid approach to security storing content. It's just hard to get right.
- lawnchair_larry 14y agoI think I just heard tptacek flip his table over from here
- tptacek 14y agoSJCL, which Mega appears to be using, includes SHA2. They could have used SHA2 if they needed a secure hash function. SJCL also includes HMAC; they could have used HMAC-SHA2 if they really needed a MAC. CBC-MAC was a bizarre choice. (I'm trying to address the general questions, like "why would I use or not use CBC-MAC", without getting into the general craziness of Mega's design or the idea of doing crypto in browser Javascript.)
- sillysaurus 14y agoIs 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.
- homedog 14y agoBasically, they use CBC-MAC to verify the integrity of their script sources. This is pretty bad because a MAC is not resistant to collisions, and given the original key, it's trivial to generate alternate data that gives the same output. A better approach would be an HMAC, using something like SHA1. Doing so makes it much more difficult to perform this type of attack.
- pjscott 14y agoWait, what? An HMAC is a MAC -- just one that happens to be constructed from a hash function in a particular way.