The short answer is "no, we can't" which every time someone proposes a new scheme seems to infuriate people (as though our inability to actually do it is a value judgement on whether or not it's a good idea).
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)
The main issue is the trust base. Allow the entire code base of a site to be pinned down to a cert (and that has to be done outside the website context, ie. in-browser), and you're halfway there.
Say, a signed webapp manifest, listing all files that are supposed to be used in that context and their hashes. On first execution, the associated key is stored, maybe compared with third party knowledge about the site (not tampered with) and key (known not-trustworthy).
After that, you know when someone else than the maintainer tampered with the code.
With that you're down to trusting the maintainer. Which makes it as good as any other code distribution scheme.
One of the top Google results for "javascript cryptography" thoroughly attacks the concept, but I'm not an expert in the area so I can't refute or confirm its claims:
I'm not a cryptographer by any means, but my first thought when reading that is can we make non-terrible in-browser javascript crypto?