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

11–20 of 84 posts

Re: A Criticism of JavaScript Cryptography

#11

Post by scotty79 »

jarrett wrote: post #8

It'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…

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.

Re: A Criticism of JavaScript Cryptography

#12

Post by eric_bullington »

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 think I accidentally downvoted you -- sorry about that.

Re: A Criticism of JavaScript Cryptography

#13

Post by mreiland »

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…

That isn't what he was saying at all

Re: A Criticism of JavaScript Cryptography

#14

Post by zAy0LfpBZLC8mAC »

bren2013 wrote: post #10
jarrett wrote: post #8

It'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.

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 threat models are not made explicit. That does not mean, though, that it's necessarily wrong to imply a sensible threat model in a given context, and to just call something "insecure" without any further explicit qualifications if it does not protect against a reasonable minimal threat model that essentially everyone essentially always has to face.

Also, it's questionable whether you can call the NSA's mass surveillance a passive attack, given that QUANTUM INSERT exists and was used, in order to attack foreign communications infrastructure.

Re: A Criticism of JavaScript Cryptography

#16

Post by bren2013 »

zAy0LfpBZLC8mAC wrote: post #14
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.

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.

Re: A Criticism of JavaScript Cryptography

#18

Post by bascule »

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 engineering web cryptography that is, for lack of a better term, total bullshit. But is the approach criticized in the Matasano post used in the real world?

Let's try an experiment! Go to google.com and type in "encrypted chat"

If your results are similar to mine, one of the top 3 results will be "chatcrypt.com". Let's read the "How It Works?" page:

> Most people thinks that if a website uses a HTTPS connection (especially with the green address bar) then their "typed-in" informations are transmitted and stored securely. This is only partially true. The transmission is encrypted well, so no third party can sniff those informations, but there is no proof that the website owners will handle them with maximum care, not mentioning that the suitable laws can enforce anyone to serve stored data for the local authorities.

Okay, so this site attempts to implement end-to-end encryption in a web browser. Except... what's the problem? Oh, it looks like chatcrypt.com isn't served over HTTPS. In fact, if we try to visit the site over HTTPS, it doesn't work at all.

chatcrypt.com claims to keep your traffic secure using end-to-end cryptography implemented in JavaScript, except the JavaScript is being served in plaintext and is therefore easily MitMable.

Top 3 Google result for "encrypted chat"

Is the Matasano post that unreasonable? (besides the title) It pretty much describes that sort of site to a tee.

Re: A Criticism of JavaScript Cryptography

#19

Post by jarrett »

scotty79 wrote: post #11
jarrett wrote: post #8

It'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…

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. The site operators themselves may become compromised (or start that way), and deliberately serve malicious JS. Users can't know when that's the case. When it is the case, the strategy you suggested offers no protection, because the "more secure" JS server is still under the control of the bad actor.

Re: A Criticism of JavaScript Cryptography

#20

Post by jarrett »

bren2013 wrote: post #10
jarrett wrote: post #8

It'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.

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

Post reply on HN