Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A Criticism of JavaScript Cryptography

bren2010.github.io

Post reply on HN
Print view View original

21–30 of 84 posts

Re: A Criticism of JavaScript Cryptography

#21

Post by jarrett »

bren2013 wrote: post #16
zAy0LfpBZLC8mAC wrote: post #14

Earlier quoted context omitted.

While you might be formally correct, your criticism still seems about as sensible as criticising someone who said "a tank made of paper sheets is not secure" because they failed to specify a threat model. After all, such a tank would be secure against a paralyzed attacker without weapons. Yes, it is important to be aware that security is always relative to a threat model, and at times it can lead to confusion when th…

This is also precisely the problem I was trying to avoid by introducing formality. Is it like saying that a tank made of paper sheets is insecure, or is it like saying that a heavily-armored tank is insecure (against a nuclear weapon)? It is never okay to omit important information like the threat model in cryptography. That information is essential to the system's analysis.

> Is it like saying that a tank made of paper sheets is insecure

Yes, I'd say it's more like that one. The technology is insecure against threat models it is almost certain to face.

> or is it like saying that a heavily-armored tank is insecure (against a nuclear weapon)?

No, I don't think it's like that one. A tank could realistically participate in a nuclear conflict, but that's not necessarily what a tank is intended for. Whereas, JS crypto is presumably intended to protect users when the remote server can't be trusted. (What else would it be for?) It can't offer such protection.

Re: A Criticism of JavaScript Cryptography

#23

Post by bren2013 »

bascule wrote: post #18

I thought this was a good post, but I wasn't impressed with the criticisms of other blog posts. Okay, perhaps I'm biased, because I wrote one of them, but how about I try to defend the other? The Matasano post is here: http://matasano.com/articles/javascript-cryptography/ Perhaps the most objectionable thing about the Matasano article is title. Otherwise it does a very good job of criticizing a particular way of engi…

I mean, it is secure against passive adversaries... but that's nit-picking.

ChatCrypt has made a large number of mistakes, though, I concur. They don't use HTTPS, it isn't open sourced, and the developer is practically anonymous.

I would still maintain that Matasano's article is problematic, though, because it has one of two effects on the reader:

1. The reader is more-than-well convinced on faulty basis that JS crypto should never be used.

2. The reader is still adamant on continuing their project, but is now alienated from a source that could have offered a plethora of helpful advice. (Example: "Please, for all that is good, use HTTPS.")

Of course, nothing will prevent the occasional surfacing of bad crypto, but their article certainly doesn't help any of its causes.

Re: A Criticism of JavaScript Cryptography

#24

Post by diafygi »

One aspect of in-browser functionality OP mentions is "offline". However, browsers are pretty cool in that they can mix offline and online. You can open a local html file and it can then make online requests. Alternatively, you can request an html file online that then can access local files.

This ability to mix offline and online content is something that I think has a lot of potential to improve client-side encryption. Specifically, client-side encryption coupled with an unhosted webapp[1].

I've been exploring this potential for my byoFS[2] project, and made an example end-to-end encrypted chat demo[3]. You can request the app anonymously (or even save it and open it locally). The app then lets the user connect an online datastore (e.g. Dropbox) to save the encrypted chats.

This separates who serves the anonymous static webapp and the authenticated datastore, and makes it much harder to target a javascript attack (the most common attack from the Snowden leaks).

[1] - https://unhosted.org/

[2] - https://github.com/diafygi/byoFS

[3] - https://diafygi.github.io/byoFS/examples/chat/

Re: A Criticism of JavaScript Cryptography

#26

Post by nadaviv »

In a project I'm working on [1], I'm planning to provide a browser extension that verifies the source code is digitally signed and that it matches the source code published on GitHub. I believe this creates a pretty good security model for a web-based app, even more so than most desktop programs.

Some more information from the security page [2]:

The browser extension provides improved security by verifying the integrity of the files served by the server. The verification is done using two factors:

- Cold storage signature verification: In addition to SSL, static files (html/css/javascript) are signed using standard Bitcoin message signatures, with a private key that is stored offline and encrypted. This ensures that the content served from the webserver was not tampered with by a third party.

- Comparing against the code on GitHub repository: The source code from the GitHub repository is built on Travis-CI and the resulting hashes are published publicly on Travis's job page. The extension ensures that the content served by the webserver matches the open-source repository on GitHub.

If an attacker gains control over the web server, he still only has access to information the web server already knows (which is very little). To get sensitive information, he would have to modify the client-side code to send back more data to the server.

For an attacker to successfully mount such an attack against someone with the browser extension, he would have to:

- Gain access to the web server.

- Gain access to the personal computer of a developer with commit access to the GitHub repository. [3]

- Commit his changes to the public GitHub repository, where they can be seen by anyone. [3]

- Gain physical access to the offline machine with the private key and know the passphrase used to encrypt it.

[1] https://www.bitrated.com/

[2] https://www.bitrated.com/security.html#browser-extension

[3] That's assuming that GitHub and Travis-CI are themselves secured. Gaining access to any of them would make those steps unnecessary.

Re: A Criticism of JavaScript Cryptography

#27

Post by notblahbl4hblah »

No such thing as a secure keystore? He needs to look harder. Aside from hardware which is tamper proof... which exists in smart cards and TPM chips... most operating systems use file system ACL's. Yes running as "root" means you can get the keys... you have to protect them...

Re: A Criticism of JavaScript Cryptography

#28

Post by trhway »

nadaviv wrote: post #26

In a project I'm working on [1], I'm planning to provide a browser extension that verifies the source code is digitally signed and that it matches the source code published on GitHub. I believe this creates a pretty good security model for a web-based app, even more so than most desktop programs. Some more information from the security page [2]: The browser extension provides improved security by verifying the integr…

>The source code from the GitHub repository is built on Travis-CI and the resulting hashes are published publicly on Travis's job page.

so, the NSA needs only to publish their hashes here (or send them only to specific clients or insert them MTM style).

Re: A Criticism of JavaScript Cryptography

#29

Post by zAy0LfpBZLC8mAC »

cryptbe wrote: post #17

Interesting coincidence. I just wrote http://vnhacker.blogspot.com/2014/06/why-javascript-crypto-i... , in which I explain the threat model implied in the Matasano's article doesn't apply to most applications.

"they just make the task of programming a crypto library a bit more fun and challenging, not riskier"

Seriously? It makes it more difficult to get things right, but the risk of getting it wrong is not increased? And that after you just described how the challenges of JS have already directly led to vulnerabilities?

Also, you mostly don't really support your own argument. How exactly does a malicious server not affect "crypto browser apps"? How does staying out of scope for PCI DSS have anything to do with security (except maybe demonstrating that PCI DSS is crap because it can so easily be circumvented)? Also, in what kind of scenario would leaking info in a referer be a problem, but leaking the same info in encrypted form would not? And how do you guarantee that your verification code is loaded fresh from the server once your application has been compromised in a browser?

Re: A Criticism of JavaScript Cryptography

#30

Post by zAy0LfpBZLC8mAC »

nadaviv wrote: post #26

In a project I'm working on [1], I'm planning to provide a browser extension that verifies the source code is digitally signed and that it matches the source code published on GitHub. I believe this creates a pretty good security model for a web-based app, even more so than most desktop programs. Some more information from the security page [2]: The browser extension provides improved security by verifying the integr…

So, you have just made GitHub the trusted third party for the world? After the X.509 CAs have so successfully protected us all these years without a single compromise or other security blunder and nobody is working on ways to get rid of those single points of failure, especially not the people behind certificate patrol or monkey sphere, that must be the best security model ever!
Post reply on HN