[jerf]

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 they can't (correctly) assume that only passive adversaries exist.

So, if that is the best in-browser crypto can do, then it is still basically useless, unless you get to choose your adversary. And "active adversary" software is off-the-shelf tech, not some sort of bizarre thing only the NSA has access to. Active adversary is the lowest baseline of attack worth talking about.

[bren2013]

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-browser crypto.

[jerf]

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 universe ("I am only being attacked by passive attackers") in order to declare your system "more secure".

Saying "I'm secure against passive attackers" doesn't mean that you're safe doing anything on your "secure" channel, because the bar for active attack is so low that that's hardly saying anything. You can be secure against "passive attackers", but you still can't verify that you haven't been attacked, in general. A definition of security in which a user blithely sticks sensitive data on a channel, unconcerned about whether the channel was attacked, is a useless definition of security... by definition, we're not talking about a user concerned with security, of any kind.

If we are talking about a security scenario where the equivalent of "active attack" is actually quite difficult and it takes a nation-state's resources, I'd be happy to discuss this argument. We've historically used some encryption at points in time where technically brute forcing it was feasible for very large entities, for instance. But the bar for active attack on the web is low here, very, very low.

[bren2013]

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 vulnerable to active attacks, and if they were attacked, nobody would know. Every cryptographer knows this. It's not a big deal.

[mpyne]

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

[jerf]

"If we are talking about a security scenario where the equivalent of "active attack" is actually quite difficult and it takes a nation-state's resources, I'd be happy to discuss this argument. We've historically used some encryption at points in time where technically brute forcing it was feasible for very large entities, for instance. But the bar for active attack on the web is low here, very, very low."

You expected to see a Perfectionist Fallacy argument, so you saw one. But it's not, because "active attacks" in this context don't require anything close to "perfection" to achieve. It's exactly the other way around... it requires near perfection to prevent them in the real world!

[mreiland]

That isn't what he was saying at all

[rmrfrmrf]

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

[jerf]

When you've been reduced to arguing about brains in vats, you're no longer having a technical conversation about security anymore. We're talking about security here.

[tptacek]

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.

[bren2013]

Then you didn't read the article.

[read]

I learned a lot from the article. I liked the research behind it and that it hoped to provide a thorough analysis.

I don't understand crypto very well so I wish the article explained things in simpler terms. Shorter would be better for me.

[tptacek]

A response that would have worked would have been "Then you didn't read the article, because XXX".

[eric_bullington]

I think I accidentally downvoted you -- sorry about that.