Hacker News Reader

Comment by m0nastic | Hacker News Reader

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).

View on HN

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.)

(Copied from http://news.ycombinator.com/item?id=3872007)

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's fair enough. I was just pointing out that not every architecture involving in-browser JS crypto suffers from the problems tptacek detailed.

Yeah, we need a crypto library like JQuery where it's open and people can use a common implementation.

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.)

What kind of vulnerability would a timing attack expose, in the use case I outlined?

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...

> Then I will pull the results off Amazon and decrypt them on a machine which is not even connected to the network.

What? How does the machine -the machine not connected to the network- get the results off Amazon?

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)

I would periodically copy the encrypted files to removeable media, then physically transfer the copy to the offline machine.

Reply on news.ycombinator.com