4 ms·
>The server could easily throw down JS code that does not perform proper crypto operations, leaks keys, or any number of other things. (Not a legal advice, con
by DenisM 13y ago
>The server could easily throw down JS code that does not perform proper crypto operations, leaks keys, or any number of other things.
(Not a legal advice, consult an attorney before following anything in this post).
There is important difference between "server could send malicious javascript" and "server does send malicious javascript". This difference becomes important when you consider the legal definition of the word "possession" - a service provider could be compelled (e.g. by a discovery request) to disclose information that he has in his possession, but he cannot be compelled to disclose information that he does not have. Information encrypted in-browser before the data is sent to the server is legally never in possession of the service provider, whereas information that is sent to the server to be encrypted is legally in possession for that brief moment, and therefore is subject to being disclosed.
In an imaginary black-and-white world only the CIA-types with the torture tools and secret jails comes after the data, and they can compel the service provider to send malicious javascript to harvest the secret if they want to. In the real shades-of-gray world there are tons of people who want to get access to someone else's data and who have to abide by the law to do that.
- daeken 13y agoIn the vast majority of cases, governments are not your adversary, or are very far down the list of priorities. They may have to follow the law, but the majority of other adversaries don't; that's why we are concerned about XSS, buffer overflows, and all other attacks against implementation flaws. That said: yes, bad crypto will defend against government 'attacks' as well as good crypto will, if you assume they're going to play by your rules. But it's still better to do it the right way.
- DenisM 13y agoI don't think you understood my post at all. My point is that adding in-browser crypto to a web app (https-only site, no external resources loaded, yada yada) has substantial impact on whether the information is disclosed or not in the end, in particular when we are talking about legally compelled disclosure. Do you agree or not?
- daeken 13y agoI agree only in the case of a legally-compelled disclosure. For all other cases, there are a million simple means by which you can break it.
- nona 13y agoI'm not so sure about that. See for example hushmail in 2007: http://www.wired.com/threatlevel/2007/11/encrypted-e-mai/ http://www.wired.com/threatlevel/2007/11/encrypted-e-mai/ While with this specific case here they intercepted the passphrase server-side, they specifically hinted that it wouldn't have made a difference with their java applet. "The extra security given by the Java applet is not particularly relevant, in the practical sense, if an individual account is targeted"
- DenisM 13y agoReading preceding paragraph to the phrase you quoted, the context implies to me they discuss whether architecture prevents hushmail from bugging java applet (it does not). They do not talk about whether they can be legally compelled to do so.