3 ms·

An email to the authors of JSCrypto

18 points by niyazpk 17y ago

zaaaaz 17y ago
Reading this is another reminder that I was not cut out for computer programming...
- aaronblohowiak 17y ago
  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 17y ago
    "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 17y ago
      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 17y ago
        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.php?storyid=38 http://thelab.fisica.unige.it/grosso/modules/news/article.ph...
        jrockway 17y ago
        Sure, but I never agreed not to speak. The rules apply to everyone except me. Duhhhh.
- akamaka 17y ago
  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.
colonelxc 17y ago
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 17y ago
  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 17y ago
    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.
- defen 17y ago
  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.
paulbaumgart 17y ago
The paper is worth reading: http://crypto.stanford.edu/sjcl/#paper 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 17y ago
  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 17y ago
    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 17y ago
      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.
  - paulbaumgart 17y ago
    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.
tdmackey 17y ago
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?

18 points by niyazpk 17y ago

zaaaaz 17y ago

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

aaronblohowiak 17y ago
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 17y ago
  "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 17y ago
    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 17y ago
      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.php?storyid=38 http://thelab.fisica.unige.it/grosso/modules/news/article.ph...
      - jrockway 17y ago
        Sure, but I never agreed not to speak. The rules apply to everyone except me. Duhhhh.
akamaka 17y ago
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.

colonelxc 17y ago

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 17y ago
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 17y ago
  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.
defen 17y ago
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.

paulbaumgart 17y ago

The paper is worth reading: http://crypto.stanford.edu/sjcl/#paper 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 17y ago
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 17y ago
  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 17y ago
    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.
- paulbaumgart 17y ago
  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.

tdmackey 17y ago

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?