4 ms·
What about loading Java applet (and communicating from JS) that handles all encrypting/decrypting? Would that take care of at least the latter concern?
by deno 15y ago
What about loading Java applet (and communicating from JS) that handles all encrypting/decrypting? Would that take care of at least the latter concern?
- tptacek 15y agoYes; you could just use Bouncycastle's Java PGP implementation, which is probably the safest option. But people hate Java, and it's increasingly disabled in browsers.
- deno 15y agoWell I thought the question was interesting because if that'd work, so would a native Web API.
- tptacek 15y agoA native web API would work! I think it'd be great if everyone could agree on some basic, high-level crypto functions, implemented in browser C, to expose to JS. You'd want the interface to look much more like Keyczar than crypto-js, though.
- deno 15y agoI was also wondering — I hope you don't mind — would it be considered safe to just verify signed messages using cryptojs? For example, let's say the environment (webapp) is bootstrapped using TLS, this includes the public key. Now could this application receive signed messages through different, unsecure channel and verify them safely using the public key received through the secure channel?
- tptacek 15y agoIf it can be safe to verify the integrity of a JS cryptosystem at all, I think it's going to turn out to be tricky to do it. Like I said elsewhere on this thread, the number of ways a web page can influence the Javascript runtime is huge, and a lot of those ways are cached.
- deno 15y agoWell the integrity of the JS cryptosystem would be no worse than the integrity of the webapp itself. I understand that one cannot trust the JS crypto for handling the private key and doing any singing & encryption because of the possibility of leaking information through side channels. That's why I was wondering if it'd be possible to use JS crypto in only one way — that is to verify messages against public key received through the secure channel. If the JS crypto only does verification, it wouldn't matter if the _public_ key is cached, as long as it can't be arbitrarily changed by another process. If the server is taken over or there's an XSS or other client-side vulnerability the bidirectional TLS would be similarly useless anyway.
- tptacek 15y agoIt's not the "math" of the crypto that concerns me; it's the actual integrity of the code performing it. So for instance, if you're trying to do RSA operations in JS, how do you know that none of the bindings in the current Javascript runtime have been exposed to attacker-controllable content? How do you know nothing in the runtime was fed by cached content read over straight HTTP? Or from an HTTPS server that has a DOM corruption flaw?
- deno 15y agoIf any of those things can be used to affect the crypto part, then they could be also used to affect the web application itself, in the first place. I'm only looking for the level of integrity, that I can get from launching the web application over HTTPS anyway.
- tptacek 15y agoIs this a point that we're dancing around here? Let's resolve it: for the most part†, you're right: the things that break clientside JS web crypto are things that break (in various degrees) the web app itself. The problem with accepting this is that the point of clientside crypto is to inoculate users from the downside risks of the simple security flaws that most applications have. What's the point of sophisticated clientside crypto if it's undone by any trivial XSS flaw? † There are issues that damage clientside JS crypto that don't blow up the app itself, but they are not the core issues I'm concerning myself with here.