3 ms·

Suppose you want to store confidential data with the server. You trust the server owners to be the good guys, but you also know that data breaches happen (e.g.

by DenisM 15y ago

Suppose you want to store confidential data with the server. You trust the server owners to be the good guys, but you also know that data breaches happen (e.g. equipment theft, FBI seizures, backup tape leaks), so if/when the breach happens the thieves will have made off with encrypted copy of your data. The only way your data is jeopardized is one of the two cases: 1. The people maintaining the service turned out to be not trustworthy, and have been harvesting the keys all along. 2. The hackers took control of the server and injected code to harvest the encryption keys for long enough to catch you in the net. If you look at the relative probabilities of these two events compared to a straight-up data leak, we're looking at orders of magnitude reduction in risk. Most people who did the right thing in the past are in the habit of doing the right things, so you can lean on the host's reputation - we've been doing that for thousands of years. Code injection on the site is much less likely than the data leak, and it is a lot less fruitful for the attacker as he would have to sit there undetected and wait for enough users to punch in their keys.

antihero 15y ago
Exactly. You can never be completely secure, but this mitigates against a large amount of potential problems.
- thaumaturgy 15y ago
  No, it doesn't. JS implementations suffer from all the same flaws that everything else does, plus a few more, and it offers no protection from any flaws that anything else is vulnerable to. "You can never be completely secure" is not a good justification for security theatre.
  - antihero 15y ago
    Well not really, because if you can verify the scripts that are loaded (and side-loading JavaScript would have to be a targeted attack that compromised either the server, or the Google API, or a malicious extension), then it guarantees end-to-end encryption for the user as opposed to having to send plaintext over the wire. How exactly would you implement a browser based crypto solution?
    - thaumaturgy 15y ago
      Preferably: That, plus a notification to the user if the signed JS has changed since the last time it was loaded, with SHA hashes of the scripts (and other data) stored directly in the browser in a way not accessible from the DOM. Since in-page scripts could still on-the-fly rewrite the functions of loaded JS, they would have to be provided read-only by the browser, or there would have to be some kind of out-of-DOM API for working with them. My hope would be that we'd see a handful of signed libraries provided and reviewed by cryptographers and that they wouldn't change very often because it would be a pain in the ass when they did. But: I am not a cryptographer or even a qualified security expert. There is probably a good reason not to do it this way.
      - antihero 15y ago
        That would be pretty fantastic as an extension that could provide essentially allow for "signed" Javascript.
thaumaturgy 15y ago
I don't follow. How is this a justification for JavaScript crypto? It might be a justification for some form of crypto, but if that's the case, why not stick with SSL + server-side encryption?
- DenisM 15y ago
  Either will work for the given scenario. The only difference I see is that with client-side crypto you can't accidentally write the key into a server log file, where as with server-side crypto it is possible. But then again at some point you will add some logging to client-side code as well, so the point will be moot - you will have to sanitize logs at point of production. Another thing is that it makes much better messaging - "the encryption key never leaves your machine".
  - thaumaturgy 15y ago
    OK, then: 1. Given that either will work for this scenario; and 2. Given that JavaScript has every weakness that the other method has; and 3. Given that JavaScript also has weaknesses that the other method does not have; then Why would you use JavaScript to solve this problem?
    - DenisM 15y ago
      Why do you think the other method does not have the same weaknesses? If the browser is compromised the key that users enters into the web page is leaked, regardless of whether you use client-side or server-side crypto. The fact that in client-side crypto in addition to the encryption key the code itself could have been tampered does not add anything to the threat... does it? The key is already presumed to have been leaked, and things can not get any worse than that. As far security is concerned, the two are equally (in)secure. And client-side crypto still has the advantage that key management is much easier to explain to the user, thus the app is more likely to be used.
      - thaumaturgy 15y ago

by DenisM 15y ago

antihero 15y ago

Exactly. You can never be completely secure, but this mitigates against a large amount of potential problems.

thaumaturgy 15y ago
No, it doesn't. JS implementations suffer from all the same flaws that everything else does, plus a few more, and it offers no protection from any flaws that anything else is vulnerable to. "You can never be completely secure" is not a good justification for security theatre.
- antihero 15y ago
  Well not really, because if you can verify the scripts that are loaded (and side-loading JavaScript would have to be a targeted attack that compromised either the server, or the Google API, or a malicious extension), then it guarantees end-to-end encryption for the user as opposed to having to send plaintext over the wire. How exactly would you implement a browser based crypto solution?
  - thaumaturgy 15y ago
    Preferably: That, plus a notification to the user if the signed JS has changed since the last time it was loaded, with SHA hashes of the scripts (and other data) stored directly in the browser in a way not accessible from the DOM. Since in-page scripts could still on-the-fly rewrite the functions of loaded JS, they would have to be provided read-only by the browser, or there would have to be some kind of out-of-DOM API for working with them. My hope would be that we'd see a handful of signed libraries provided and reviewed by cryptographers and that they wouldn't change very often because it would be a pain in the ass when they did. But: I am not a cryptographer or even a qualified security expert. There is probably a good reason not to do it this way.
    - antihero 15y ago
      That would be pretty fantastic as an extension that could provide essentially allow for "signed" Javascript.

thaumaturgy 15y ago

I don't follow. How is this a justification for JavaScript crypto? It might be a justification for some form of crypto, but if that's the case, why not stick with SSL + server-side encryption?

DenisM 15y ago
Either will work for the given scenario. The only difference I see is that with client-side crypto you can't accidentally write the key into a server log file, where as with server-side crypto it is possible. But then again at some point you will add some logging to client-side code as well, so the point will be moot - you will have to sanitize logs at point of production. Another thing is that it makes much better messaging - "the encryption key never leaves your machine".
- thaumaturgy 15y ago
  OK, then: 1. Given that either will work for this scenario; and 2. Given that JavaScript has every weakness that the other method has; and 3. Given that JavaScript also has weaknesses that the other method does not have; then Why would you use JavaScript to solve this problem?
  - DenisM 15y ago
    Why do you think the other method does not have the same weaknesses? If the browser is compromised the key that users enters into the web page is leaked, regardless of whether you use client-side or server-side crypto. The fact that in client-side crypto in addition to the encryption key the code itself could have been tampered does not add anything to the threat... does it? The key is already presumed to have been leaked, and things can not get any worse than that. As far security is concerned, the two are equally (in)secure. And client-side crypto still has the advantage that key management is much easier to explain to the user, thus the app is more likely to be used.
    - thaumaturgy 15y ago