Hacker News new | past | comments | ask | show | jobs | submit login

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.




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.


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?


Is that a question? I don't understand the question. "Put your money where your mouth is" doesn't sound like a rebuttal.

I've no idea what you're talking about.


> I don't understand the question.

Let me break that down for you:

1) formulate an argument for a setting in which content-controlled browser Javascript is a sensible place to deploy cryptography.

1.a) Give yourself the full benefit of every facility the web programming model gives you, up to the limit of installing browser extensions.

2) What's a system like (1) that has worked well, and would be resilient to a determined adversary?

So, he's claiming to have shown that content-controlled browser javascript crypto is worse that useless because it allows good people to inadvertently leak secrets. All you have to do to prove him wrong is just tell him a use case where it would make sense and then cite an example where that worked well* and would be resilient to a determined* adversary.

So, all you have to do is say "chatcrypt.com's use case makes sense and chatcrypt rocks. Here I show that it is unbreakable until long after the stars cool, and no amount of kneecap cryptography will lessen the adversery's burden."

* He's giving you two wiggle words already, you can define them however you'd like.


He means crypto from servers can't be trusted. You need something better. You need crypto running in a browser extension.

If I understood your article correctly, when you (bren2013) refer to in-browser crypto you mean crypto code is delivered from the server. But that's not the only in-browser crypto you can get. You can also get in-browser crypto delivered from a browser extension. Under this second definition of in-browser crypto, the following sentence in the article isn't accurate:

there is nothing in-browser crypto can do to defend against active adversaries.

(I admit I didn't read the article thoroughly.)




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: