Thank you! The Matasano article, as I mentioned in another comment, for some reason assumes that SSL is not used, which is not the case with aes.io.
235 karma · joined July 18, 2012
"And if you have SSL, why do you need Javascript crypto? Just use the SSL."
aes.io uses SSL _and_ JS crypto on top of it to make sure server-side data is always encrypted, with keys unkown to the server side.
1. very easy for MITM-type attacks: this is negated by using SSL
2. JavaScript is too "malleable" for crypto - this argument is not very clear; yes, JS is "malleable" - so what, if we can be reasonably sure it is not "infected", by using server-side tools like signatures and SSL? This is highly debatable...
3. server breaches easily propagate to users: this is a real issue, but it is a real issue with many products that auto-update themselves, such as OSes (with patches/updates), browsers, anti-viruses, etc. Thus although this is a valid concern, it is part of everyday life of most Internet users,and not something JS crypto is specifically bad at.
Re: OpenPGP vs PKCS1: historical reasons (have a well-tested code for PKCS1). If at some point it becomes clear that OpenPGP is much better, adding it won't be a big issue.
To answer your questions:
1. all encryption/decryption is done in JS. BouncyCastle java source code is used (slightly tweaked for performance) - it is compiled into JS using Google's GWT compiler.
2. flash is only used for triggering file save dialog, similarly to downloadify, in browsers that do not support HTML5 alternatives. In Chrome, which supports <a download>, flash is not used (100% JS/HTML5)
3. problems mentioned in the post you referenced can be generalized into two groups: (a) hijacking the server to serve "trojaned code", and (b) inherent JS limitations such as the absence of proper PRNG.
Concern (a) is valid. However, most client systems have auto-updating software products installed, with auto-updating enabled (browsers auto-update themselves; anti-viruses and OSes do the same, etc. - the Flame worm was using Windows Update to sneak in, I think). It is a universal issue in the modern "connected" world, and most users have to live with this threat if they want to use the Internet in any meaningful way; I can't imagine a person eyeballing the source of every patch they compile/apply on their system.
Concern (b) is not really valid now, IMHO. As mentioned above, it is possible to use a solid open-source crypto library either directly (e.g. Stanford Crypto JS library) or compile one into JS, to use proper PRNG, etc. With proper testing (standard/published test vectors; cross-platform tests - encrypt in JS and decrypt in java, etc.) it is possible to make good crypto in JS. And things like side-vector attacks do not look relevant here, as the attacking code needs to run on the client, which means the client has been compromised already.
Yes, this is a kernel issue, already fixed in 3.3.x. But Canonical has no intention of backporting it to 12.04 (3.2 kernel). And we are talking here about "just working", not installing an unsupported kernel manually from a dev repository.
For some reason Canonical decided to sacrifice stability and focus on something most users don't think they need (Unity).