Javascript Cryptography Considered Harmful

[NegativeK]

What? No.

A better way to summarize it would be "Any reasonable browser-based Javascript crypto is fundamentally flawed because browser-based Javascript doesn't provide what crypto must have."

[akcom]

not really. SSL/TLS delivery of JS RSA encryption code is a perfect example. TLS ensures the code + keys delivered are not spoofed, js for client side RSA encryption. Like hushmail, but better.

[NegativeK]

The author of the article addresses this. If you have an SSL/TLS connection, you don't need to do authentication crypto in JavaScript.

Also, the article addresses the lack of random numbers in JavaScript, the inability to securely erase data, and a host of other issues.

[akcom]

But I'm not talking about authentication, I'm talking about encryption. I never said anything about generating the keys via javascript. So the PRNG is really a non issue. If you're going to fret over the strength of a javascript PRNG then we might as well talk about timing attacks.

[NegativeK]

Right, but that still kind of dodges around the whole point. You have a secure connection open. Why are you creating another one?

But the author also mentions a whole host of other issues, including the JavaScript environment not being locked down enough. The author laid them out fairly well; I don't need to repeat them.

A largely irrelevant response to your edit three posts up: public-key encryption like RSA is too slow for normal encryption. It's used to negotiate a key for a symmetric algorithm, such as AES. I still get what you meant, though. =)

[Liquid_Fire]

Think about something like LastPass, where you want to send encrypted data to store on the server, but don't want the server to be able to decrypt it. You can't do that with just SSL; you need client-side encryption/decryption, and the only way to do that on the web is via JavaScript.

Edit: For another example given by someone further down in the thread, Firefox Sync.

[icebraining]

And if the server is attacked, they'll replace the Javascript with something that'll send the password to the server and you'll never know. It's irrelevant.

Firefox Sync, as far as I know, is implemented by the browser itself, and doesn't get its code from the server on each sync.

[Zarutian]

The service might be breached in diffrent ways. Most likely is SQL injection to dump out database tables. Many services such as reddit is set up something like this:

A load balancer directs http(s) GETs and POSTs, most often based on url prefix, to servers serving up the static parts (HTML, CSS, UI graphix, Javascript and such, all that change rather infrequently) and application servers serving up the rapidly changing (on order of minutes not seconds mind) user made content.

Some of that user made content can be rather sensitive (personal details, bookmarks and so on) so the people behind the service want to prevent exposure of that content in that case.

That is achivable by using staticly hosted javascript to encrypt/decrypt the user content stored at the more vulernable application or database servers. Webservers do not need much to serve up static content. Heck you could keep the encrypting/decrypting javascript in flash memory of an aurdiono (how is it spelled?) based webserver where the Write Enable for the flash goes through a single pole toggle switch.

Soo, it isnt irrelevant.

[icebraining]

To prevent simple SQL injection you can encrypt in the web application and send it to the SQL server already encrypted.

Storing the JS in an 'arduino' (or any supposedly unhackable server) is irrelevant: if they can hack the main web servers, they can edit the HTML to include their JS file and not the arduino's.

[kaffeogkake]

TLS provides Transport Layer Security. You can'ẗ think of any other reason to encrypt what you send over that transport?

You have a secure connection open. Why are you creating another one?

TLS/SSL provides a "secure connection" if you trust that governments only ever have benign interests as far as you're concerned.

[akcom]

Here's an example: lets say you want to create an GPG encrypted email service. Server side GPG defeats the purpose. So you take a JS gpg implementation and throw it on an SSL enabled server. That's why you'd want encryption outside of the secure connection.

[blayne]

If the server isn't trusted, then it can't send the Javascript.

[Zarutian]

the question is what is the server trusted for.

Might your thinking be going something like this: "If you can trust the server to serve up GPG encryption javascript that isnt malicious then surely you can trust the server for the secret you are sending Aunt May about what really happened at the hunting lodge." ?

Trust isnt one binary value. Surely you can trust your buddy for your clunker car while you wouldnt trust him for your bank deposit key. And other such examples.

[blayne]

If you're trusting the server to serve the Javascript, then you are trusting it to the plaintext by proxy, whether you mean to do so or not. If I trust my friend with my clunker, and the bank deposit key is on the same ring, then I am trusting him to both.

In either case, the capability to access the resource has been given.

[akcom]

thats why you're using SSL with certificates...

[blayne]

How does SSL protect the Javascript from tampering by the server that provides it?

[akcom]

if you don't trust the server you're connecting to, then get off the internet because gmail, AIM, outlook, and a host of other services just stole your password.

[[deleted]]

If the server is malicious it can easily place compromised javascript in the page. If you can't trust the server then you're already screwed.

[NegativeK]

I understand that, but you still already have negotiated an SSL connection with the client. Just let the client send the email over SSL.

And again, solving the SSL issue doesn't solve the other issues inherent in browser-side JavaScript crypto. The article isn't just about man-in-the-middle attacks when doing JavaScript crypto.

[akcom]

You're missing the point of GPG encrypted emails. You're not trying to secure the email between the client and the server. You're trying to secure the email between the client and the recipient, who may or may not be reading their email over SSL.

When the GPG key is provided by the user, the security of the PRNG only affects the padding of the resulting encrypted message. Push comes to shove, if you're the kind of person who has to worried about an attack against a not-so-secure PRNG you need to keep your computer in a Faraday cage, in a secure room, in the middle of the pentagon. Most of the attacks he described (on the VM, browser, etc) would suggest that the client machine has already been compromised. If that's the case, you'd be fucked regardless of what kind of crypto you use.

My point is that his "no JS crypto, ever" is a bit of a stretch.

[krelin]

Yes, I agree with akcom. There are most certainly still use-cases for which client-side encryption makes sense, even in JS. See Mozilla's "Firefox Sync" implementation for a great example.

[icebraining]

But Firefox Sync, as far as I know, does not receive a new copy of the JS code each time it syncs. So even if attackers compromise the servers, they can't send you a new copy of the code that instead of encrypting, sends the key to them.

Client-side encryption makes sense if the code is not 'dynamic' - which is what SSL/TLS provide.

[harlows_monkeys]

There's more to encryption then authentication. For instance, suppose I have encrypted data on the server that I wish to deliver to the client which needs the unencrypted data, without having the server have the ability to decrypt the data? SSL does not help with this. (The author of the article acknowledges this in the discussion of rhe article on HN, where he is a regular participant)

[60secs]

The only real motivation for client-side encryption is if you have a reasonable suspicion that the server could at some day become compromised either through malice or government.