
An email to the authors of JSCrypto - niyazpk
http://corte.si/posts/security/jscrypto.html
======
colonelxc
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?

~~~
cortesi
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.

~~~
colonelxc
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.

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

------
paulbaumgart
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.

~~~
cortesi
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.

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

~~~
cortesi
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.

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

~~~
aaronblohowiak
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.

~~~
jrockway
"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.)

~~~
aaronblohowiak
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.

~~~
sundarurfriend
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...](http://thelab.fisica.unige.it/grosso/modules/news/article.php?storyid=38)

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

