Hacker News Reader

Comment by trekkin | Hacker News Reader

The article has many points, but it seems that they can be grouped together around three themes:

1. very easy for MITM-type attacks: this is negated by using SSL

2. JavaScript is too "malleable" for crypto - this argument is not very clear; yes, JS is "malleable" - so what, if we can be reasonably sure it is not "infected", by using server-side tools like signatures and SSL? This is highly debatable...

3. server breaches easily propagate to users: this is a real issue, but it is a real issue with many products that auto-update themselves, such as OSes (with patches/updates), browsers, anti-viruses, etc. Thus although this is a valid concern, it is part of everyday life of most Internet users,and not something JS crypto is specifically bad at.

View on HN

By "malleability", we mean that code loaded in the future can monkey patch away the random number generator or AES block cipher function. I'm pretty sure that isn't debatable.

You keep saying that you mitigate this problem by controlling your pages 100%. Congratulations, you have gone farther than many of the JS crypto apps I've looked at; many of those bug their pages with Google Analytics, or with Typekit.

But that doesn't mitigate the problem that your users can't police you. They are relying entirely on your promise not to deploy code that will surreptitiously defeat the security of AES (or whatever ciphers you're using). And because JS is malleable, it is untenably hard even for an expert to attempt to validate your code by hand.

In other words, "I don't understand #2, so let's assume it's not a problem and handwave it away." Alas, it is a problem, and a critical one. Pray tell, how do you check the VM, from inside the VM sandbox? Guess what: you have no way to do that, not in JavaScript. That's another chicken-and-egg problem which is insurmountable with client-side, in-page JS.

I cannot do that from inside the sandbox, but as I completely control the page, not just one script on it, I can be reasonably sure no rogue script is running on it (by using SSL).

I've read the Matasano article, don't assume I didn't. Most of the points in it are negated by controlling the page 100% and using SSL.

I'm confused. In way does your application protect users against you? You control the code that handles the users encryption secrets. Your users have no effective way to police you.

Why not just have the users send you their plaintext, and rely on SSL/TLS for the rest of your security? It seems like that provides effectively the same security.

Reply on news.ycombinator.com