Stanford Javascript Crypto Library • Hacker News Board

Re: Stanford Javascript Crypto Library

#21

Post by jnbiche » Thu, Aug 29, 2013, 5:36 PM UTC

j_m_b wrote: post #16

With the recent revelations that private internet companies (ISPs) are colluding with the NSA, I very much doubt the security of certificates issued by a "certificate authority". I really like the idea of Secure Remote Password (SRP) which uses a Diffie–Hellman-like key exchange instead of relying on third party certificates. The main difficulties I see to SRP adoption are: 1) Not all browsers natively support SRP, t…

This doesn't necessarily solve your problem, but new versions of Firefox, Chrome, Opera, and IE all provide CSPRNGs. It's experimental, but it's been available in Firefox for several versions. So if you have a modern browser, just open your console window, and try: window.crypto.getRandomValues(typedArray)

On mobile, this random number generator is unfortunately not available on Android's browser, although it is available on Chrome for Android, Firefox Mobile, and Safari on iOS and up.

There's also a full browser-based Crypography API in the works. You can see the draft here: http://www.w3.org/TR/WebCryptoAPI/

Once all of this is implemented, the chicken and egg problem is solved, since the browser will then have native crypto primitives available. At that point, the main argument I see against browser-based crypto in JavaScript is the malleability of the Javascript runtime. And if you believe that's an intractable problem, then you should probably reconsider the use of any language for crypto that can be monkey-patched, including common server-side languages like Python, Ruby, and to a certain extent PHP.

Re: Stanford Javascript Crypto Library

#22

Post by ape4 » Thu, Aug 29, 2013, 5:39 PM UTC

dubcanada wrote: post #15

brador wrote: post #11

Universities should do more open source projects. How about a university that funds open source works exclusively?

I'm sorry but I have to ask, is this sarcasm? I can't really tell.

In case of lack of sarcasm. Check out http://en.wikipedia.org/wiki/Berkeley_Software_Distribution The core of iOS

Re: Stanford Javascript Crypto Library

#23

Post by malandrew » Thu, Aug 29, 2013, 5:41 PM UTC

meshko wrote: post #4

Obligatory quote from http://www.matasano.com/articles/javascript-cryptography/ WHAT ABOUT THINGS LIKE SJCL, THE STANFORD CRYPTO LIBRARY? SJCL is great work, but you can't use it securely in a browser for all the reasons we've given in this document. SJCL is also practically the only example of a trustworthy crypto library written in Javascript, and it's extremely young. The authors of SJCL themselves say, "Unfortuna…

What if the sites used SJCL by default, but urged the user to install an official browser plugin that detects the presence of SJCL on a page and falls back to the browser's own copy of SJCL, always trusting it over any copy sent over the wire. It's not perfect but at least gives users a stepping stone to secure communications.

The biggest problem with getting users to adopt crypto is giving them stepping stones to something better, and giving them subtle explanations of risks with lesser involved approaches. I understand the fear of giving the user a false sense of security. We should try to mitigate doing so, while still giving a path to adopt best crypto practices over time. Wholesale adoption of crypto by society is only going to happen when people promoting crypto realize that crypto, like everything else competing for the attention of users has a conversion funnel.

Re: Stanford Javascript Crypto Library

#24

Post by tlrobinson » Thu, Aug 29, 2013, 5:42 PM UTC

jonpaul wrote: post #20

Anyone interested in signed JavaScript? Initiatives like this are great. However, I'm most interested in signed JavaScript. I'm surprised that there isn't more of a discussion going about this since JavaScript crypto is near worthless if it's served from an untrusted server. For example, let's say that you have an application that uses client-side crypto in JavaScript. Then let's assume that the server (that serves u…

Yes, however isn't this sort of what HTTPS is supposed to accomplish?

Re: Stanford Javascript Crypto Library

#25

Post by [deleted] » Thu, Aug 29, 2013, 5:46 PM UTC

gcommer wrote: post #7

meshko wrote: post #4

Obligatory quote from http://www.matasano.com/articles/javascript-cryptography/ WHAT ABOUT THINGS LIKE SJCL, THE STANFORD CRYPTO LIBRARY? SJCL is great work, but you can't use it securely in a browser for all the reasons we've given in this document. SJCL is also practically the only example of a trustworthy crypto library written in Javascript, and it's extremely young. The authors of SJCL themselves say, "Unfortuna…

You may be interested in the defensive js ( http://www.defensivejs.com/ ) project which seeks to securely isolate JavaScript code from maliscous javascript being injected on the page. It also provides a verified crpyto library implementation. Combine this with HTTPS and I think doing the crypto on the client is certainly feasible (and has been implemented by mega (well, they messed up a few things, but that was an is…

[deleted]

Re: Stanford Javascript Crypto Library

#26

Post by 3JPLW » Thu, Aug 29, 2013, 5:50 PM UTC

anon1385 wrote: post #10

gcommer wrote: post #7

Earlier quoted context omitted.

You may be interested in the defensive js ( http://www.defensivejs.com/ ) project which seeks to securely isolate JavaScript code from maliscous javascript being injected on the page. It also provides a verified crpyto library implementation. Combine this with HTTPS and I think doing the crypto on the client is certainly feasible (and has been implemented by mega (well, they messed up a few things, but that was an is…

>This is wrong, because using both means that the web service we are using (for example) never knows our plaintext password, so they can't attack us under the assumption of password reuse, like in http://xkcd.com/792/ TLS doesn't protect you against a malicious site that is collecting passwords. Even if you were to examine the javascript code to verify that it isn't sending the plaintext[1], they could send a differe…

You must always trust something. In the case of a SpiderOak-like service, you must trust one of their client implementations to use it. Whether it is their compiled binary (which isn't even open source[0] "yet") or a javascript client in the browser delivered securely. Even in the case of tarsnap, with open source implementations that don't self-update, you must trust your own code review or somebody else's -- not a trivial task.

[0]. https://spideroak.com/faq/questions/35/why_isnt_spideroak_op...

Re: Stanford Javascript Crypto Library

#27

Post by jonpaul » Thu, Aug 29, 2013, 5:53 PM UTC

tlrobinson wrote: post #24

jonpaul wrote: post #20

Anyone interested in signed JavaScript? Initiatives like this are great. However, I'm most interested in signed JavaScript. I'm surprised that there isn't more of a discussion going about this since JavaScript crypto is near worthless if it's served from an untrusted server. For example, let's say that you have an application that uses client-side crypto in JavaScript. Then let's assume that the server (that serves u…

Yes, however isn't this sort of what HTTPS is supposed to accomplish?

Not as far as I know... I could run a server that serves up HTML/JS and if that JS was modified by an attacker who hacked the server, consumers of my HTML/JS wouldn't know regardless of whether it's served up on HTTPS or not. Please correct me if I'm wrong.

Re: Stanford Javascript Crypto Library

#28

Post by gcommer » Thu, Aug 29, 2013, 5:55 PM UTC

anon1385 wrote: post #10

gcommer wrote: post #7

Earlier quoted context omitted.

You may be interested in the defensive js ( http://www.defensivejs.com/ ) project which seeks to securely isolate JavaScript code from maliscous javascript being injected on the page. It also provides a verified crpyto library implementation. Combine this with HTTPS and I think doing the crypto on the client is certainly feasible (and has been implemented by mega (well, they messed up a few things, but that was an is…

>This is wrong, because using both means that the web service we are using (for example) never knows our plaintext password, so they can't attack us under the assumption of password reuse, like in http://xkcd.com/792/ TLS doesn't protect you against a malicious site that is collecting passwords. Even if you were to examine the javascript code to verify that it isn't sending the plaintext[1], they could send a differe…

Assuming that the web service is doing proper client side authentication most of the time (which, with enough effort, can be verified), and then gets coerced into sending compromised JS at some point in the future - we still have better security than the alternative of no client side security at all. Sure the increased chance of a malicious update is a real threat, but it is better than that attack not needing to be performed at all.

A further incremental improvement could be made using a Mega-style root of trust (ironically, an article explaining how they messed up the implementation explains it best: http://fail0verflow.com/blog/2013/megafail.html). Only the initial loader page (with embedded hashes and MACs) needs to be checked for whether or not it has changed on each page load. If you want to be immune from a later malicious update, you just have to manually save the loader page and open it instead of re-requesting it from the Mega. Yes, during an update they can stop serving the old scripts and deny access, but you will at least always know when an update has occurred.

Re: Stanford Javascript Crypto Library

#29

Post by untothebreach » Thu, Aug 29, 2013, 5:56 PM UTC

tlrobinson wrote: post #24

jonpaul wrote: post #20

Anyone interested in signed JavaScript? Initiatives like this are great. However, I'm most interested in signed JavaScript. I'm surprised that there isn't more of a discussion going about this since JavaScript crypto is near worthless if it's served from an untrusted server. For example, let's say that you have an application that uses client-side crypto in JavaScript. Then let's assume that the server (that serves u…

Yes, however isn't this sort of what HTTPS is supposed to accomplish?

HTTPS just tells you that you are talking to the 'right' server. It doesn't tell you anything about the validity of the javascript that the server is sending you.

Re: Stanford Javascript Crypto Library

#30

Post by gcommer » Thu, Aug 29, 2013, 5:57 PM UTC

3JPLW wrote: post #26

anon1385 wrote: post #10

Earlier quoted context omitted.

>This is wrong, because using both means that the web service we are using (for example) never knows our plaintext password, so they can't attack us under the assumption of password reuse, like in http://xkcd.com/792/ TLS doesn't protect you against a malicious site that is collecting passwords. Even if you were to examine the javascript code to verify that it isn't sending the plaintext[1], they could send a differe…

You must always trust something . In the case of a SpiderOak-like service, you must trust one of their client implementations to use it. Whether it is their compiled binary (which isn't even open source[0] "yet") or a javascript client in the browser delivered securely. Even in the case of tarsnap, with open source implementations that don't self-update, you must trust your own code review or somebody else's -- not a…

The point anon1385 is trying to make about JavaScript clients is that they can be changed at any time by the web service provider, where as open source clients can be 'verified' once by the open source community and then can't be easily changed by the service provider (unless they have an auto updater, which Tarsnap does not)