3 ms·
Agreed the article is not very insightful. Another place where it misses the point entirely: > The problem is, having established a secure channel with SSL, y
by geertj 12y ago
Agreed the article is not very insightful. Another place where it misses the point entirely:
> The problem is, having established a secure channel with SSL, you no longer need Javascript cryptography; you have "real" cryptography.
This overlooks a major use case of client-based cryptography where you don't want to expose any private keying material to the server.
- davrosthedalek 12y agoNot really. If you don't trust the server to hold the key, you can't trust the client you downloaded from the very same server.
- gnur 12y agoIt's not always about trust. Sometimes it's more about the burden of having the keys. mega is a good example of why client side encryption is used. They don't want the burden / liability of knowing what is stored on their server. (they probably know it anyway, but the idea stands).
- wtbob 12y agoThat protects mega (the server); it does nothing to protect the client. As the client, I care about my protection.
- geertj 12y agoWhile you are correct that a server can serve me malicious Javascript encryption code that discloses my keys, there's a big difference: the act cannot be hidden. If my secret keying material instead is on some company's servers it can be taken surreptitiously (by court order or not).
- geertj 12y agoI'm not sure why HN doesn't let me reply to danielweber's comment. Thread is getting too deep? I admit that in practise you're not going to check the Javascript. But from the point of view of someone trying to get their hands on private material, the difference is huge. If the private material is on a server, a simple court order (or not) can give you access to potentially millions of customer records. But if you wanted to do dragnet collection when client-side crypto is in use, you now have millions of small but non-zero risks to get exposed. [EDIT: spelling]
- danielweber 12y agoWhile it may be mathematically impossible for the server to give you hostile code with no way at all of you detecting it, in practice you are not going to check the JavaScript you download each time. Nor does the browser have any way of doing version control for you, or of verifying what's actually running.
- tptacek 12y agoNo, it does not overlook that "major use case". You're confused between wanting something to work in a specific way, and whether things actually work that way. If there's a "#1 most common fallacious reasoning strategy" employed by advocates of browser crypto, it's that one.
- geertj 12y agoWow, sensitive topic? No need for ad hominem. Thank you very much.