Actually, I think in some limited circumstances, JS crypto could be useful for a kind of "separation of trust." For instance, I am considering a service at the moment which would involve people uploading confidential information. The uploads will be fairly large, so a lot of bandwidth will be required (optimistically assuming it gets traction.) One architecture I am considering is a small dedicated HTTPS server which provides a self-contained webpage-plus-JS program to encrypt the upload and send it for storage on Amazon S3. Then I will pull the results off Amazon and decrypt them on a machine which is not even connected to the network. The advantage to this architecture is that it will scale arbitrarily but require me to secure only relatively modest dedicated resources, despite being used for transmission of confidential information. Because it uses a dedicated HTTPS server serving a self-contained page doing all the crypto, it avoids tptacek's objections to JS crypto in the browser (E.g., the server can provide the random seed in the JS itself, HTTPS prevents MITM attacks, etc.)
So, you're scheme would require the long answer...
;)
Which is that it sounds rather complicated (which makes my security-sense go off, but certainly isn't a fatal indictment) and that I'd really need to either do an active evaluation of the system or get several reassurrances that someone else decent (ideally someone much smarter than me) did and it checked out before I'd be remotely comfortable using it or recommending it.
That design is not obviously impossible to make work, but have you thought about timing attacks? There is no obvious way to make JS take key- and data-independent time to encrypt something. (Turning this into a usable attack is nontrivial, obviously.)
It could conceivably leak the key and/or data being sent. If the key is random, leaking it does not expose unrelated data; and if you're uploading via HTTPS, exposing the key does not even expose the protected data unless the attacker also has access to S3.
Data-dependent timings could conceivably allow a bad guy to deduce something about the data being sent.
Note that this is all highly speculative; I'm not convinced it's truly impossible, but it's one of those attack scenarios where "put a gun to the sysadmin's head" begins to look like a pleasant and trouble-free option...
I guess it's possible the machine (connected to the Internet) pulling from Amazon is also connected to a network with the machine that can decrypt (but can't access the Internet)
(Copied from http://news.ycombinator.com/item?id=3872007)