A Criticism of JavaScript Cryptography
bren2010.github.io
A Criticism of JavaScript Cryptography
1–10 of 84 posts
Re: A Criticism of JavaScript Cryptography
#2One 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.
Re: A Criticism of JavaScript Cryptography
#3I really enjoyed reading this. Certainly put the browser security model in a new perspective for me.
Re: A Criticism of JavaScript Cryptography
#4[deleted]
Re: A Criticism of JavaScript Cryptography
#5One 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-browser crypto.
Re: A Criticism of JavaScript Cryptography
#6Wow.
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 construction is said to have a higher level of security.
This is what we need more in security discussions. So many discussions, here on HN but also, well, everywhere, are really misunderstandings about which threat model to assume. People get into hot-headed fights about whether some solution somewhere is or is not "secure", when really all they disagree about is which definition of "secure" to use.
Well done! I propose that security related blog posts take some time out to casually define these terms over and over again, for a while, until we can all just assume them known and be done with all the vague imprecise nonsense.
Re: A Criticism of JavaScript Cryptography
#7One 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-…
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.
Re: A Criticism of JavaScript Cryptography
#8It's not clear to me if the author is endorsing the use of browser crypto in any particular scenario. Regardless, probably the most common reason for wanting browser crypto is to protect the data before it hits the server, thus protecting against a malicious or compromised server.
For example, consider a web-based mail client. You want to send an encrypted message, say via PGP, and you don't want the server to be able to read it, even if the server is evil. You'd like to be able to do the PGP encryption 100% in-browser, with no browser plugins or extensions necessary.
I think that's the most common category of use-case for browser crypto. Unfortunately, it's one where browser crypto plainly doesn't work. The whole point here is to defend against an evil server, but if the server is evil, it will send you evil crypto JS. TLS doesn't help you. Nobody's impersonating the server or altering the JS file in transit. You're getting an authentic copy of the JS file from the real server. It just happens to be an authentic copy of an evil JS file.
Given that, what can you do with browser crypto, practically speaking?
Re: A Criticism of JavaScript Cryptography
#9Earlier 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…
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.
Re: A Criticism of JavaScript Cryptography
#10It's not clear to me if the author is endorsing the use of browser crypto in any particular scenario. Regardless, probably the most common reason for wanting browser crypto is to protect the data before it hits the server, thus protecting against a malicious or compromised server. For example, consider a web-based mail client. You want to send an encrypted message, say via PGP, and you don't want the server to be abl…
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.