Hacker News Reader

Comment by gorset | Hacker News Reader

If you are running javascript on a page from a server, you are trusting the server with your plaintext.

You are trusting the server, you are trusting the quality of every line of code on the server that has a hand in generating the page content (since any DOM corruption flaw will let you trivially backdoor the encryption), and you're trusting every third party server from which HTML or JS content is sourced.

It's a terrible, terrible idea.

But if you wanted to, you could verify the authenticity of the code. If you're just sending plaintext off into the void, then you have zero control whatsoever. You could also open up Wireshark to verify your plaintext isn't being transmitted anywhere.

How exactly are you verifying the authenticity of the code? By looking at the Javascript code? Even if you're among the 0.0000000% of users who could look at JS AES and know if it's backdoored, how do you know if any of the Javascript functions it's calling have been backdoored? Similarly: what does it matter if you can see plaintext on the wire? The attacker siphoning off your data can re-encrypt it for themselves. You helpfully provided them a library to do exactly that.

When was the last time you checked whether your compiler wasn't producing backdoored code? How about those chips on your motherboard? Perhaps an instruction or two are being executed without your consent?

You are just being paranoid at this point.

Like someone mentioned, using this to encrypt state secrets? Stupid idea. Using it to provide some level of trust that the server never sees the plaintext data? Pretty reasonable.

Why are you protecting against the server never seeing plaintext data? In case the server is compromised? If the server is compromised, then so is your JS!

The difference between traditional compilers, chips on motherboards, and so on and so forth, are that you aren't downloading and using a fresh copy every time.

If it were possible to securely store some JavaScript in your browser (trust-on-first-use), or otherwise verify that the JS hadn't changed since the last time you used it, and if that JS weren't accessible from the DOM, and if that JS were well-written and used standard practices and had been reviewed by cryptographers, then maybe it would be OK to use.

...But then again, you've just reinvented SSL.

Seems like browser extensions would be the way to go.

Here's the SJCL demo: http://bitwiseshiftleft.github.com/sjcl/demo/

SJCL has a bug in their RSA implementation. We're using a good bit of their code with a few changes for our web client. The idea being that we don't want to store passwords, so the webclient stores an encrpyted private key and everything sent to the server must be signed.

The users id is a sha256 hash of their public key and all we keep are the public keys.

Working so far in FF and Chrome, not even trying it in IE

Not sure what you mean, SJCL doesn't have an RSA implementation.

Hmmm, indeed it doesn't. Who's RSA implementation am I using, guess I've forgotten.

Probably Tom Wu's JSBN implementation...

Are you at liberty to disclose what you're using this for? i'm interested in learning about legitimate use cases for SJCL.

The auth system for a stock/asset exchange.

Yes, exactly. I would love to have cross device SSO and authentication. Having proper cryptography available in the browser (either built-in or through a extension) would make that easier to make. As a bonus: phishing resistant.

And what alternative would you suggest? An application is not acceptable.

Reply on news.ycombinator.com