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

31–40 of 84 posts

Re: A Criticism of JavaScript Cryptography

#31

Post by orthecreedence »

jarrett wrote: post #20
bren2013 wrote: post #10

Earlier quoted context omitted.

lol, This is exactly what I was trying to stop people from doing! I'm not endorsing or damning it--I'm talking about it sensibly and objectively so people can learn to use it properly. Please read the article again carefully. I think you'll find the answers to your questions.

> so people can learn to use it properly. That's the part to which I'm objecting. As I asked above, what is the proper use of JS crypto? What real-world application do you have in mind where JS crypto's level of security is adequate?

Packaged in a signed browser extension is a good start. Or packaged in a signed desktop app that runs JS to drive the UI (xulrunner, node-webkit, ...).

In general, anywhere you aren't basically doing what amounts to an eval() on an external resource (so packaging everything locally, aggressively filtering XSS attacks) can be a good use of JS crypto.

I don't think JS crypto itself is the issue. I think the issue is more pulling your code from an external, ultimately untrusted source. You can do this in many languages, and it's equally a Terrible Idea in all of them. Granted, some things auto-update and can verify an update via a packaged public key, but the model of continuously downloading code on each run, while easier on app developers, is a ticking time bomb for crypto.

Re: A Criticism of JavaScript Cryptography

#32

Post by mpyne »

bren2013 wrote: post #9
jerf wrote: post #7

Earlier quoted context omitted.

Let me say it again: As a user, you can't verify that you're secure against the attackers.This is my important point, not whether a particular chosen attack was blocked. Therefore, if you care at all about security, you can't trust the channel. You're only looking from the POV of the attacker, but you've got to consider all the POVs, including the users, and not impute to them knowledge that they can't have about the…

This is an example of the Perfectionist Fallacy I was talking about in the article. You can't verify that someone isn't MiTM'ing with a stolen certificate. You can't verify that the CA hasn't been coerced into forging a valid certificate. You can't verify that your government hasn't ordered that computer manufacturers install surveillance devices. That doesn't mean that the internet is unusable. Some things are vulne…

I didn't get the impression jerf was arguing for perfect security, as much that they were saying that securing only against a passive attacker is as useful for the user as not using TLS at all.

Selecting a threat model is all well and good, but if you select an artificially easy threat model to defend against then you're not really helping users (in this case, helping them against random evil ISPs?)

Re: A Criticism of JavaScript Cryptography

#33

Post by rmrfrmrf »

jerf wrote: post #7
bren2013 wrote: post #5

Earlier quoted context omitted.

No, you don't get to pick your adversaries, but you do get to pick the strongest one you wish to be secure against. Or for that matter, can be secure against. I briefly mentioned Diffie-Hellman key exchanges to provide an example of another common primitive that's only secure against passive adversaries. (DHKEs are typically used in peer-to-peer applications.) Also, if you keep reading, I mention several uses for in-…

Let me say it again: As a user, you can't verify that you're secure against the attackers.This is my important point, not whether a particular chosen attack was blocked. Therefore, if you care at all about security, you can't trust the channel. You're only looking from the POV of the attacker, but you've got to consider all the POVs, including the users, and not impute to them knowledge that they can't have about the…

The problem with this argument is that you stop passing the buck when it's convenient for your argument, not to its actual conclusion. The only reality any one of us can actually be sure of is each of our own minds[0], therefore the only way to keep information secure is to never share it. Even then, our brains in vats could be under constant monitoring and decoding, therefore making secrecy a futile exercise altogether.

Because a solipsistic worldview is, perhaps, irrelevant to everyday life, we begin to operate on assumptions based on information that's infeasible for us to know for certain. This is what you must do to talk about security on the Internet: limit the domain of the problem by making assumptions about the Internet's infrastructure. You're right that it will never be possible to share a secret on the Internet without risk, that's not the point of this article or any others that indicate the flaws of JavaScript cryptography.

[0] http://en.wikipedia.org/wiki/Solipsism

Re: A Criticism of JavaScript Cryptography

#34

Post by cryptbe »

zAy0LfpBZLC8mAC wrote: post #29
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…

> 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?

Well it seems that you misunderstood which challenges I was talking about. Lack of types is a big problem, but besides that everything else doesn't make the risk bigger.

> How exactly does a malicious server not affect "crypto browser apps"?

I didn't claim that malicious servers won't be able to affect crypto browser apps. What I said is that in these apps you have to trust the server already, so it doesn't make sense to consider them untrusted.

> 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)?

It's exactly the point. When people say "javavascript crypto is harmful" they don't consider use cases where it's really useful, even just to circumvent PCI DSS.

> 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?

I don't understand this question.

> And how do you guarantee that your verification code is loaded fresh from the server once your application has been compromised in a browser?

Because every time I refresh my browser I get a chance to get some trusted code from the server.

Re: A Criticism of JavaScript Cryptography

#35

Post by tptacek »

I suppose I'm expected to give a full-throated defense of the Matasano post, which I wrote, but I'm not going to. While I don't dislike the post as much as this author appear to, I don't much like it either. I wrote it in a single draft, all at once, as a sort of message board comment I'd write once and maybe in the future refer back to. I didn't promote it on HN and I'm not the reason it keeps getting cited.

None of this bickering changes a simple truth: when a web mail provider claims to provide "NSA-proof" end-to-end encryption, hosted in Switzerland just to be safe, using software that you don't have to install on your computers at all, then you need to assume that web mail provider can read your email, and so can anyone who can coerce that provider into doing something. If you believe that --- and you should --- then I don't care what you think about the rest of the Matasano article.

Re: A Criticism of JavaScript Cryptography

#36

Post by tinco »

jarrett wrote: post #19
scotty79 wrote: post #11

Earlier quoted context omitted.

It still might protect you if you won't access server while it's compromised. It protects you from someone just hacking your server, downloading all the data and getting away. Also you might serve files that do the encryption from different server that's smaller, better protected, more stable, that less people have access to.

> It still might protect you if you won't access server while it's compromised. The end user can't know when that's the case. > Also you might serve files that do the encryption from different server that's smaller, better protected, more stable, that less people have access to. That doesn't provide any assurance to the end user that the JS isn't malicious. Remember, "compromise" doesn't just refer to a drive-by hack…

> > It still might protect you if you won't access server while it's compromised. > The end user can't know when that's the case.

This is the entire point of the article. You can't know if it's the case, you can't either with any software distribution. When you type 'apt-get install opensshd', how do you know if you're getting the package from an uncompromised server?

You just have to trust that the public keys you got are the right ones, and their private keys have not been stolen.

So what the author is saying is that regarding that aspect web crypto is at roughly the same level.

The big problem of course is that there is evidence that the whole CA system is much less reliable than the old GPG signing party system.

Re: A Criticism of JavaScript Cryptography

#37

Post by tptacek »

bren2013 wrote: post #23
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 cryp…

How about, instead of arguing that readers of an article are more convinced than they should be about something you yourself appear to be convinced of, you put your money where your mouth is and formulate an argument for a setting in which content-controlled browser Javascript is a sensible place to deploy cryptography. Give yourself the full benefit of every facility the web programming model gives you, up to the limit of installing browser extensions (at which point you're no longer talking about content-controlled code). What's a system like this that has worked well, and would be resilient to a determined adversary?

Re: A Criticism of JavaScript Cryptography

#38

Post by tptacek »

skrebbel wrote: post #6

Wow. A construction or implementation is secure if an adversary, given a certain level of power, is unable to achieve a given objective. The level of power an adversary is assumed to have and their ultimate objective is called the threat model. If a new construction is secure under a new threat model that either increases the amount of power an adversary can have or makes the adversary's objective broader, the new co…

This sounds important, but the distinction between "passive" and "active" attackers has come up in every discussion of JS crypto I can remember on HN, and indeed in every discussion of TLS (see, for instance, every discussion of why certificate authorities are necessary and why self-signed certificates are insecure "despite using exactly the same cryptography as CA-signed certificates").

I do not believe this is a dimension that has been missing from previous discussions, but perhaps you can use the search bar below to find a debate about JS crypto where it was missing and where the result was misleading to readers.

Re: A Criticism of JavaScript Cryptography

#39

Post by tptacek »

bren2013 wrote: post #5
jerf wrote: post #2

One problem with the "passive adversary" attack is that even if the nonce+HMAC protocol defeats the passive adversary, you as a user have no way of verifying whether or not your adversary is passive. Or whether they exist, or, indeed, anything about them, as in the real world, you don't get to pick your adversaries. The user needs a way to determine whether the connection is secure before they can trust it, because t…

No, you don't get to pick your adversaries, but you do get to pick the strongest one you wish to be secure against. Or for that matter, can be secure against. I briefly mentioned Diffie-Hellman key exchanges to provide an example of another common primitive that's only secure against passive adversaries. (DHKEs are typically used in peer-to-peer applications.) Also, if you keep reading, I mention several uses for in-…

I read the whole article and the impression I have is that all the uses you have for in-browser crypto in the current web programming model involve resistance to passive-only attackers.

Re: A Criticism of JavaScript Cryptography

#40

Post by tptacek »

d1str0 wrote: post #15

Why do people use styles like these that push all the content uncomfortably to the sides? 40% of the screen is dedicated to what? The blog title and a link home. Edit: http://i.imgur.com/62l4zCG.png 500% better

Because there is an optimum range of characters per line for readability.
Post reply on HN