So, forgive me for asking a dumb question. What would be a better approach here? I'm assuming that SHA1 doesn't cut it.
(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.)
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.
Don't do crypto in browser Javascript!
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).
... for attackers with some knowledge of side-channel attacks, which are almost impossible to block from Javascript.
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.
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".
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.
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.