Hacker News Reader

Comment by tzs | Hacker News Reader

Minor quibble:

   WHY CAN'T I USE TLS/SSL TO DELIVER THE JAVASCRIPT
   CRYPTO CODE?

   You can. It's harder than it sounds, but you safely
   transmit Javascript crypto to a browser using SSL. The
   problem is, having established a secure channel with SSL,
   you no longer need Javascript cryptography; you have "real"
   cryptography. Meanwhile, the Javascript crypto code is still
   imperiled by other browser problems

My minor quibble is that there are other reasons one might want cryptography besides establishing a secure channel, and so using SSL does not necessarily solve whatever problem one was trying to solve with JavaScript.

For instance, the client might need data that is stored encrypted on the server, and you want to do the decryption on the client.

View on HN

I think the fourth of fifth graf of this (poorly written, I agree) article explicitly calls out that there are reasons beyond a secure channel why you might want clientside browser crypto.

So, I'm actually going a step past the obvious argument against jscrypto ("this is an inferior way to build a secure channel"). Not only is it an inferior secure channel, but it's also an inferior and dangerous place to try to build crypto functionality even if you're using SSL/TLS to establish a secure channel.

Put bylines on your articles. You are not The Economist.

There is one (and probably only one) case when js crypto makes sense. And that is when server operator wants to convince third party that he cannot access encrypted data at rest stored on the server. Client side JS based encryption (and by the way also things like hushmail) does not help in any way when you don't trust the server.

> And that is when server operator wants to convince third party that he cannot access encrypted data at rest stored on the server.

Or the server actually doesn't want to store unencrypted data.

...server operator wants to convince third party that he cannot access encrypted data at rest stored on the server

Indeed. Or simply because the same party owns the server and the client.

Exactly. I always considered JS Crypto orthogonal to TLS. You still want TLS for authentication and establishing a secure channel to ensure you're getting the right code from a person you trust.

Javascript (or generally, client-side) crypto would still be invaluable for other things. If it can be implemented safely, you could do stuff like GPG for mails and OTR for instant messaging. For Javascript, that appears to be a pretty big "if", though. If it can't be implemented safely, well, then it's a matter of opinion. Some will argue the crypto is still useful despite a couple of viable attack scenarios, others will argue that an appearance of securiy is much worse than no security at all.

Reply on news.ycombinator.com