An email to the authors of JSCrypto | Hacker News Reader

An email to the authors of JSCrypto

corte.si

18 pointsniyazpk17 comments

I remember a discussion on here before of why using JS crypto (different implementation) was a bad idea (in short, a mitm could give you a broken jscrypto functions which don't really encrypt).

So no, you wouldn't want to use this in place of TLS, but the authors give some decent reasons why you actually might want to do this:

One major reason is the need to encrypt data before uploading it to a server; this is useful where the server needs to store data but doesn't wish to see it in the clear. It can also be used in desktop applications written in Javascript - for example, Firefox extensions.

Can anyone think of other good reasons?

You can't generalise MITM and injection attacks to "Javascript crypto is bad". There's an idea floating around called "host proof hosting" - or in the Clipperz parlance, "zero-knowledge applications" - that I think could be potentially very important in future, and that relies entirely on Javascript crypto. The only problem is that I haven't seen it done right yet - every application I've looked at that claims to implement this paradigm has some enormous, glaring shortcoming.

I'm working on an epic tldr; blog post and an associated project release related to this - keep an eye out for it next week.

You're right about that, I certainly over generalized the issue. I should have just stuck with "javascript crypto shouldn't be used in place of TLS."

The host proof hosting stuff is pretty interesting. Some people implement something similar when using dropbox, by encrypting the files before they are synced. A disadvantage of this method (other than being cumbersome), is that you lose the bandwidth savings of Dropbox's deltas.

I believe that another problem with non-native crypto implementations is that they are more vulnerable to timing attacks, because you have less control over what the computer is actually doing.

Note: I am not a cryptographer, and I don't even play one on TV.

Javascript and cryptography are two words that should never be used together. I can't believe people think this provides some decent form of security. Instead of worrying about the security of some javascript crypto implementation you should be more focused on wtf kind of problem this actually solves without introducing a slew of new weaknesses. TLS/SSL provides end to end encryption and doing any random crypto in javascript doesn't provide anything on top of that. And if you aren't using TLS/SSL then the code is still coming from your server in plaintext. If it is sent in plaintext then it can be replaced by an attacker therefore requiring you to send it over https and since you are already doing that why bother with javascript crypto when you can just send the data over the secure connection you already made?

The paper is worth reading: http://crypto.stanford.edu/sjcl/#paper It reads fairly well.

Interesting how they built their CSPRNG, using mouse movements gathered as the user interacts with a page (and optionally cookie data):

  Since we extract 2 bits of entropy per mouse move sample,
  we need 128 samples to generate a 256-bit AES key. Our data 
  shows the that median time for the generator to be seeded 
  to the default level of 128 samples is 9, 28 and 41 seconds 
  on the survey, forum and blog, respectively.

I wonder if there's a good way to buffer the entropy securely so it doesn't have to wait so long for every encryption.

In a nutshell, that's almost what the Fortuna family of PRNGs do. In the JSCrypto implementation, entropy is collected from the mouse movements continuously, and like all Fortuna implementations it uses a clever dance using a block cypher and multiple entropy pools is to "buffer" the entropy. Google "fortuna" for more information.

Edit: Sorry. I deleted my comment. I thought you were being redundant and hadn't read the article. I didn't notice that you were the author. can someone vote this comment's parent up?

That's a bit over-zealous - even if I hadn't been the author of the article, noting that Fortuna PRNGs can be thought of as "buffering" entropy would have been worthwhile in this context.

Got it, thanks. It wasn't clear to me from the paper or the reference implementation that it did that, but it makes sense it would.

Reading this is another reminder that I was not cut out for computer programming...

How can that possibly be a discussion-enhancing comment on a news site lovingly called "Hacker News"?

Please mind that signal to noise ratio is something that we have to all work hard to maintain.

"This doesn't belong on Hacker News is signal?"

(Even less signal-ish is this post. But I don't care about signal-to-noise. What I care about is when there's no longer any signal, like Reddit and Digg.)

I suspect that unmitigated habits of noisiness contribute more noise than the combination of noisiness and inverse noise.

"I don't care about signal-to-noise. What I care about is when there's no longer any signal, like Reddit and Digg."

Disregard for standards leads to digg.

Four monks decided to meditate silently without speaking for two weeks. By nightfall on the first day, the candle began to flicker and then went out. The first monk said, "Oh, no! The candle is out." The second monk said, "Aren't we not suppose to talk?" The third monk said, "Why must you two break the silence?" The fourth monk laughed and said, "Ha! I'm the only one who didn't speak."

Edit: Source: http://thelab.fisica.unige.it/grosso/modules/news/article.ph...

Sure, but I never agreed not to speak. The rules apply to everyone except me. Duhhhh.

I voted you up, not because I agree, but because for me, this was more a reminder as to why JavaScript is a tricky language, and not one that should be jumped into as mindlessly as many of us do.

Reply on news.ycombinator.com