Javascript encryption • Hacker News Board

Re: Javascript encryption

#61

Post by thaumaturgy » Mon, Jul 04, 2011, 5:43 PM UTC

antihero wrote: post #59

thaumaturgy wrote: post #40

Earlier quoted context omitted.

No, it doesn't. JS implementations suffer from all the same flaws that everything else does, plus a few more , and it offers no protection from any flaws that anything else is vulnerable to. "You can never be completely secure" is not a good justification for security theatre.

Well not really, because if you can verify the scripts that are loaded (and side-loading JavaScript would have to be a targeted attack that compromised either the server, or the Google API, or a malicious extension), then it guarantees end-to-end encryption for the user as opposed to having to send plaintext over the wire. How exactly would you implement a browser based crypto solution?

Preferably:

That, plus a notification to the user if the signed JS has changed since the last time it was loaded, with SHA hashes of the scripts (and other data) stored directly in the browser in a way not accessible from the DOM.

Since in-page scripts could still on-the-fly rewrite the functions of loaded JS, they would have to be provided read-only by the browser, or there would have to be some kind of out-of-DOM API for working with them.

My hope would be that we'd see a handful of signed libraries provided and reviewed by cryptographers and that they wouldn't change very often because it would be a pain in the ass when they did.

But: I am not a cryptographer or even a qualified security expert. There is probably a good reason not to do it this way.

Re: Javascript encryption

#62

Post by oconnore » Tue, Jul 05, 2011, 4:26 PM UTC

thaumaturgy wrote: post #37

oconnore wrote: post #17

Be careful: if you are using a javascript library to encrypt data, you get protection from eavesdroppers, but not from man-in-the-middle attacks. If I can alter data that you send/receive over the wire, I can simply modify your aes function calls to xor the data with a predictable sequence that I generate. The only way to prevent this that I have thought of is to store the site (which has presumably already been acqu…

> *...if you are using a javascript library to encrypt data, you get protection from eavesdroppers..." Nope. Replay attacks. Piece of cake. The number of things that JavaScript does better than SSL is 0.

I don't think you know what you are talking about. If your authentication is implicit in the decryption of the messages, replaying that data will accomplish nothing.

For example, if I share a secret "password" with my server, I can do this in javascript using any symmetric cipher:

    ToServer: "My name is oconnore"
    ToClient: cipher(iv1, "(C1) Hi oconnore. Use this! iv2=rng()"++msghash, "password")
    ToServer: cipher(iv2, "(C2) Thanks, give me my data please!"++msghash, "password")
    ToClient: cipher(iv3, "(C3) , and iv4=rng()"++msghash, "password")
    ...

If an attacker repeats any of these messages, the client/server will discard them based on the counter. Of course, for real use you would need to use public key crypto to avoid storing passwords in what is essentially plaintext, but I thought this would illustrate how replay attacks are a non issue.

Of course, as noted before, all this is irrelevant if you are sending your code over a channel vulnerable to MITM...

Re: Javascript encryption

#63

Post by antihero » Wed, Jul 06, 2011, 7:41 AM UTC

thaumaturgy wrote: post #61

antihero wrote: post #59

Earlier quoted context omitted.

Well not really, because if you can verify the scripts that are loaded (and side-loading JavaScript would have to be a targeted attack that compromised either the server, or the Google API, or a malicious extension), then it guarantees end-to-end encryption for the user as opposed to having to send plaintext over the wire. How exactly would you implement a browser based crypto solution?

Preferably: That, plus a notification to the user if the signed JS has changed since the last time it was loaded, with SHA hashes of the scripts (and other data) stored directly in the browser in a way not accessible from the DOM. Since in-page scripts could still on-the-fly rewrite the functions of loaded JS, they would have to be provided read-only by the browser, or there would have to be some kind of out-of-DOM A…

That would be pretty fantastic as an extension that could provide essentially allow for "signed" Javascript.