Live data from Hacker News

Stanford Javascript Crypto Library

crypto.stanford.edu

61–70 of 91 posts

Re: Stanford Javascript Crypto Library

#61
post #51
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…

It occurred to me the other day that it should be pretty simple to write a script that gets loaded first on the page and removes all subsequent scripts, then loads them itself, checking the MD5/SHA1 of the script against a known good value, stored in that script's attributes. Then you could decide to not load scripts that do not match the correct hash. It could even ping the server to alert it to broken scripts.

[deleted]

Re: Stanford Javascript Crypto Library

#62
post #47
post #30

Earlier quoted context omitted.

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)

Ah, very good point. And the provider can send uniquely compromised versions to individuals to reduce their chance of detection, as well.

Hushmail.

Re: Stanford Javascript Crypto Library

#63
post #57
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…

Matasano are experts here; I'm not; but here's my argument: There's parts of their post that I don't like: "If you don't trust the network to deliver a password, or, worse, don't trust the server not to keep user secrets, you can't trust them to deliver security code." "How can you do that without SSL? And if you have SSL, why do you need Javascript crypto? Just use the SSL." I wonder about the implicit threat model.…

This is where you lose me:

"...I'd figure that if they were injecting JS to steal my password, or subtly poison my RNG, and if they were doing that to everyone..."

To everyone — maybe that would get found out, maybe it wouldn't. But it doesn't have to be done to everyone. That backdoor in the JS could be served to only you. Maybe only certain times of day. How are you going to know?

Re: Stanford Javascript Crypto Library

#65
post #63
post #57

Earlier quoted context omitted.

Matasano are experts here; I'm not; but here's my argument: There's parts of their post that I don't like: "If you don't trust the network to deliver a password, or, worse, don't trust the server not to keep user secrets, you can't trust them to deliver security code." "How can you do that without SSL? And if you have SSL, why do you need Javascript crypto? Just use the SSL." I wonder about the implicit threat model.…

This is where you lose me: "...I'd figure that if they were injecting JS to steal my password, or subtly poison my RNG, and if they were doing that to everyone..." To everyone — maybe that would get found out, maybe it wouldn't. But it doesn't have to be done to everyone. That backdoor in the JS could be served to only you. Maybe only certain times of day. How are you going to know?

We are all open to that. Google, MS and Apple send us software updates that have root privileges on our computers. They hold the keys to our digital houses. We allow them to enter and fix our plumbing and electrical wiring almost every week, and rarely can see or understand what they "fixed". We are with our pants down.

Re: Stanford Javascript Crypto Library

#66
post #63
post #57

Earlier quoted context omitted.

Matasano are experts here; I'm not; but here's my argument: There's parts of their post that I don't like: "If you don't trust the network to deliver a password, or, worse, don't trust the server not to keep user secrets, you can't trust them to deliver security code." "How can you do that without SSL? And if you have SSL, why do you need Javascript crypto? Just use the SSL." I wonder about the implicit threat model.…

This is where you lose me: "...I'd figure that if they were injecting JS to steal my password, or subtly poison my RNG, and if they were doing that to everyone..." To everyone — maybe that would get found out, maybe it wouldn't. But it doesn't have to be done to everyone. That backdoor in the JS could be served to only you. Maybe only certain times of day. How are you going to know?

If its targeted just at you, its a different class of attack. Of course, no technology can protect against all classes of attack.

I'm just saying that there are situations where JS crypto might be useful, such as increasing the difficulty of conducting mass surveillance in secret.

Secret mass surveillance being, of course, a big topic recently.

What people need is not security that defends perfectly against every threat in theory, but no one uses in practice.

Re: Stanford Javascript Crypto Library

#67
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…

Don't you need to trust a certification authority in order to be sure that the browser running SRP hasn't been tampered with?

Re: Stanford Javascript Crypto Library

#69
post #65
post #63

Earlier quoted context omitted.

This is where you lose me: "...I'd figure that if they were injecting JS to steal my password, or subtly poison my RNG, and if they were doing that to everyone..." To everyone — maybe that would get found out, maybe it wouldn't. But it doesn't have to be done to everyone. That backdoor in the JS could be served to only you. Maybe only certain times of day. How are you going to know?

We are all open to that. Google, MS and Apple send us software updates that have root privileges on our computers. They hold the keys to our digital houses. We allow them to enter and fix our plumbing and electrical wiring almost every week, and rarely can see or understand what they "fixed". We are with our pants down.

And it's pants all the way down! Can we even trust our chips? But we stagger on.

Re: Stanford Javascript Crypto Library

#70
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…

In an Bitcoin-related open-source project I'm currently working on (still in early alpha stages), I'll be using a browser extension that verifies the response using offline signatures (with a way to verify the public key using the Bitcoin network) and compares against builds from the github repository (using travis-ci).

Here's some explanation from the website FAQ:

        #### Browser extension
        Our browser extension provides improved security by verifying the integrity
        of the files served by the server. The verification is done using two factors:

        - **Cold storage signature verification:**
          In addition to SSL, static files (html/css/javascript)
          are signed using standard Bitcoin message signatures on an offline machine
          (the private key was created on that machine, and has no other copies)
          and appended to the response body as a comment.

        - **Comparing against the code on GitHub repository:**
          The source code from the GitHub repository is built on Travis-CI,
          and the resulting hashes are published publicly on Travis's job page.
          The extension compares the web server response against those hashes.

        If a potential attacker gains control over the web server, he still only has
        access to information the web server already has (which is very little).
        To get sensitive information, he would have to modify the client-side code
        to send back more data to the server.

        For an attacker to succesfully mount such an attack against someone with the
        browser extension, he would have to:

        1. Gain access to the web server
        1. Gain access to the personal computer of a developer with commit access
           to the Github repository
        1. Commit his changes to the public GitHub repository, where they
           can be seen by anyone
        1. Gain **physical access** to the offline machine with the private key

        For users without the extension, he would only have to do the first step.
        It is highly recommended to install the extension.

        Install extension

        #### Public key verification
        To prevent an attacker from modifying our published Bitcoin public key,
        its permanently embedded into Bitcoin blockchain in a way that is
        [nearly impossible](https://en.bitcoin.it/wiki/Weaknesses#Attacker_has_a_lot_of_computing_power)
        to modify (and becomes exponentially more difficult as time goes by).

        The public key can be verified by taking the following procedure:

        1. Take the SHA256 of the domain name ("****.com")
        2. Create a Bitcoin address using that hash as the private key
        3. Find the **first** transaction with that address as its *output address*
        4. The *input address* of that transaction is our public key

        If its ever required to change the public key, the announcement
        will be signed with the old public key.
Post reply on HN