Stanford Javascript Crypto Library

http://crypto.stanford.edu/sjcl/

by austengary • 13 years ago

147 86 13 years ago

crypto.stanford.edu

nsmartt2• 13 years ago

This could lead to a rise in services offering client-side encryption. A 'better' homepage might help.

lisper• 13 years ago

Anyone who needs a "better" home page probably ought not to be using it.

nsmartt2• 13 years ago

Developers with a budding interest in cryptography should certainly be using this, even if they shouldn't be asking users to trust their work. Your mentality excludes a rather large set of users who may not realize what they've found.

Also, a homepage with a pitch, a visually appealing design, etc would likely generate some buzz from people who aren't interested in using it but are interested in the concept. This could very well lead to discovery by developers who would otherwise have never found it.

anonova• 13 years ago

Mega does something like this. Encryption is done client-side.

https://en.wikipedia.org/wiki/Mega_(website)#Data_encryption

meshko• 13 years ago

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, "Unfortunately, this is not as great as in desktop applications because it is not feasible to completely protect against code injection, malicious servers and side-channel attacks." That last example is a killer: what they're really saying is, "we don't know enough about Javascript runtimes to know whether we can securely host cryptography on them". Again, that's painful-but-tolerable in a server-side application, where you can always call out to native code as a workaround. It's death to a browser.

gcommer3• 13 years ago

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 issue in their use of crypto, not the crypto implementation) and 0bin).

EDIT: Also, the site you are quoting is explicitly complaining about people using JavaScript security but NOT over HTTPs, and they claim that there is no advantage to using JavaScript crypto when you are using TLS anyways. 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/

__alexs• 13 years ago

It also provides a verified crpyto library implementation.

Verified by who?

anon13852• 13 years ago

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 different chunk of code any time you access the site in the future. Either because the site is malicious -- as in the above example -- or because it has been compromised (whether that be by skiddies or three letter agencies with legal papers).

The only 'benefit' javascript crypto gives you is that it makes it easier for people to develop apps where the users data is encrypted before it is sent to the server (such that the server can never decrypt it). However doing this in a javascript web app totally negates that since the server can just send a compromised chunk of js any time it feels like. So the additional security to the user is basically zero.

If you want to seriously create a service like this don't use javascript inside the browser. Do what Tarsnap does: provide an open source native client that does not automatically update.

[1] and let's not pretend that modern javascript is at all readable, in the age of minification and asm.js

Everlag• 13 years ago

Perhaps the key to crypto in the browser would be to implement it in extensions rather than on webpages? Extensions run in a higher level of security clearance, are sandboxed from the rest of the page, and are much more intolerant of code injection.

zellyn• 13 years ago

http://techblog.netflix.com/2013/07/nfwebcrypto-web-cryptogr...

jonknee2• 13 years ago

Built into the browser would be even better (like SSL).

oscargrouch• 13 years ago

downloading and executing code on the fly as in the web browser its a broken design problem..

browsers are being patched for a long time now.. to fit into sophisticated models.. it came all over here, by using duct tape.. but now it can be patched anymore to get into the next level.. it cant reach the next level because its broken by design.

how long until people face the reality?

malandrew• 13 years ago

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.

jorgeleo• 13 years ago

Steve Jobs is turning in his thumb... you just suggested the p word

sneak6• 13 years ago

Then instead of backdooring the sjcl, the malware would just steal the plaintext out of the DOM or hook into keystroke handlers.

The problem is JavaScript.

pdubs• 13 years ago

It's useful if you store things in local storage.

feral2• 13 years ago

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. Its too black-and-white for me. In it, you either trust the server or you don't.

But security and privacy, for me, for large numbers of users, is all tradeoffs and games, shades of grey.

Consider: maybe our computers are uploading the private files of everyone who runs Windows to Microsoft. I don't know for sure, but I'd gamble that they aren't. I don't think MS would they take the risk of some security researcher catching the anomalous traffic on the network. The threat of the resulting PR storm would help keep MS honest, at that scale. So I'd expect MS would try pretty hard to fight a government leaning on them to do that.

Lets say that, in future, all data on the worlds most popular social network is encrypted client side. My ID is just a public key, and my browser encrypts all my traffic, using a JS package the social network securely delivers me. (Over SSL. With great care.)

That'd be a similar scenario to MS. I'd be trusting them when I enter my password into the JS they sent me, that is running in my browser. But, again, 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, probably some security researcher would call them on it. And so, they'd be incentivised not to.

That's a fundamentally different situation to the current one, where if Facebook gives all our data away, its pretty hard for someone outside their organisation to find out. Probably they could gamble on keeping it secret.

So that's why I think the 'Javascript Considered Harmful' post is too strong, in its "you either trust the server or you don't" attitude.

I also think that we aren't going to get anyone using crypto, unless its delivered seamlessly in the browser. There has been good crypto available for years (e.g. GPG on the deskop plugged into thunderbird). But I think we've learned that if its even slightly harder to use, then end users are going to ignore it.

And the way to deliver seamless ease-of-use to a wide audience is on the web. And we badly need easy-to-use privacy these days. So I think it'd be a shame if posts like that discouraged research into JS crypto.

(I can think of other arguments:

e.g. where you want to trust a server now (e.g. to encrypt and backup a document) but decide not to trust it later (decide to abandon the document because in the years since you uploaded it, you think the server/company is compromised - or you ask to be e-mailed the ciphertext)

or regulatory differences: I don't think its the same thing legally to demand or steal a copy of someones server side data, and any server side keys, as it is to demand that the javascript be changed to snoop future passwords as users enter them into their browser application?)

Again, I'm no expert in this area; corrections welcome.

graue• 13 years ago

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?

marcopolo• 13 years ago

If the maintainer is reading this, I submitted a pull request that significantly speeds up CCM encryption by using arraybuffers. I'd love to see it merged in: https://github.com/bitwiseshiftleft/sjcl/pull/89

brador• 13 years ago

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

dubcanada• 13 years ago

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

ape4• 13 years ago

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

goldfeld• 13 years ago

Relatedly, I'm looking for Javascript checksum implementations, especially sum24 or any other good 24bit hashing algorithm, and I couldn't find anything. Does anyone know of canonical hashing implementations for CRC and checksum (not crypto-level, I need short, short hashes) for JS?

methehack4• 13 years ago

I was thinking about this too -- but if they compromised your encryption JS couldn't they also compromise your checksum JS?

devx• 13 years ago

Great. Now can we see more services implement easy to use client-side encryption before uploading data to their servers?

tptacek4• 13 years ago

Great. Now we can pretend we're secure instead of grappling with the problem that we're not. :)

Observe that SJCL's own authors warn about this problem.

rixoff• 13 years ago

Sure! Check out crypton.io. SpiderOak is going to be shifting towards this method. Although we already use client-side cryptography, it's in fat clients written in Python. We're going to reimplement the client using Crypton, which uses SJCL.

j_m_b3• 13 years ago

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, though this is changing. You therefore need a good javascript library for interfacing with the server. This of course leads to 2) No trustworthy javascript crypto library exists with the possible exception of the incomplete SJCL. The biggest problem current JS libraries have is that of 3) generating random numbers. Because there is no cryptographically secure rand() javascript implementation, the solution I've seen is to use mouse movement or other user input to generate random numbers. The problem with this is that it takes ~30 seconds of random movement from the user to "seed" the generator! One interesting method I've thought about is to use http://www.fourmilab.ch/hotbits/ to retrieve random numbers, but this just leads back to depending on a third party for secure communications. I think an efficient, cryptographically secure pseudo random number generator is the biggest deficit to js-based crypto tools.

tptacek4• 13 years ago

I'm not sure how to engage with the idea that SRP is a viable replacement for certificate authentication; it only works with the client and server have a pre-shared key.

I very much do not trust certificate authorities, but observe that you don't have to trust certificate authorities to make the security architecture of TLS work. Already, CA compromises have a minimized impact on properties like Google Mail, whose certificates are pinned in Chrome and Firefox. Soon, all properties will get the same privilege, when we adopt schemes like TACK that allow dynamic certificate pinning.

As soon as a critical mass of browsers support dynamic pinning, it will become drastically less profitable to target CAs, because attempts to present forged certificates to Internet users en masse will quickly be detected.

j_m_b3• 13 years ago

it only works with the client and server have a pre-shared key

What "pre-shared key" are you referring to in SRP? The only a priori value needed for SRP is the safe prime (N) and generator (g).

jnbiche• 13 years ago

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.

j_m_b3• 13 years ago

I didn't know about the window.crypto.getRandomValues(typedArray). Thanks!

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.

Someone else in this thread mentioned http://www.defensivejs.com/ and I think it is going in the right direction.

MarkMc• 13 years ago

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

jonpaul4• 13 years ago

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 up the client-side app) is hacked and the client-side application is modified to send your private keys back to the hacked server, there is currently no way you'd know as the consumer of that client-side application. If signed JavaScript existed, then browsers could alert you that the JavaScript that you're running has been modified and doesn't match the signature, so it refuses to execute it.

tlrobinson2• 13 years ago

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

jonpaul4• 13 years ago

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.

untothebreach• 13 years ago

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.

sdevlin4• 13 years ago

If you don't trust the server, you're screwed anyway.

jonpaul4• 13 years ago

Maybe, maybe not. But if you only rely upon the client-side feature of the app and if code signing is employed, you could safely use the app without fear of potentially your private data being stolen (assuming the original code doesn't send private data to the server).

tghw5• 13 years ago

Consider CDNs and static content domains. It's generally easier to break or MITM a CDN or static content server without people noticing. This way, you could trust that the code you received was what you were expecting.

tghw5• 13 years ago

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.

    <script src="scriptloader.js"></script>
    <script src="jquery.min.js" data-md5="a1b2..."></script>

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.

sdevlin4• 13 years ago

How would this protect you against a malicious server?

ballard• 13 years ago

There needs to be both signed javascript and signed native code plugins for javascript (similar to JNI). Both of these require significant leadership because of the fragmented nature of existing implementations. The upside is an ability to deliver native crypto libraries and other plugins that remove the potential of having its internals introspected or MITMed.

The protections against malicious code have to be there, so it would be the same order-of-magnitude of installing any other browser plugin.

nadaviv• 13 years ago

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.

        <a class="btn btn-primary" href="TODO">Install extension</a>

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

sneak6• 13 years ago

Signed by whom? Signatures distributed how?

methehack4• 13 years ago

What do you guys think about a service (think pingdom) that you set up to periodically request a js file from your server and check it against a known good checksum?

EDIT: to spell this out, you would, self host the stanford library, for example, and have this service verify it against a known good checksum.

tptacek4• 13 years ago

You don't just need to authenticate sjcl.js (or whatever). You need to authenticate every page element that can influence the JS, because JS is malleable. The service you propose won't work.

methehack4• 13 years ago

Well, couldn't checksum the whole page?

I know that creates a big pain in the ass in terms of modifying the page and in terms of making the page dynamic, but bracketing those two concerns -- why wouldn't that work?

justapor• 13 years ago

It's JavaScript, not Javascript..

nly• 13 years ago

The W3C have a draft API for hosted JavaScript cryptography:

http://www.w3.org/TR/WebCryptoAPI/

Netflix, of all people, have implemented a flavour of this at least once for Chrome:

https://github.com/Netflix/NfWebCrypto

franze2• 13 years ago

i built Masel with it (as a demo for our local javascript meetup) i.e.: http://replycam.com/m/ pretty much serverless encrypted message sharing. its MIT L. and unfinished https://github.com/franzenzenhofer/masel

RazerM• 13 years ago

Off-topic, but 'masel' is the Scots word for 'myself'.

franze2• 13 years ago

i named it after the jidish http://en.wikipedia.org/wiki/Mazel_tov (written in german "masel tov") masel stands for "a drop from above". so basically "masel" as "drop" of privacy. but well i coded it during a train ride while i was drinkng some beer (reached the balmer peak with it http://xkcd.com/323/ )

sneak6• 13 years ago

Let's all congratulate austengary on successfully trolling HN's star quarterback.

leke• 13 years ago

I was playing with a javascript crypto library and grease monkey. Here's a quick and early facebook demo: https://www.youtube.com/watch?v=3HlQJWXlknE

yawgmoth• 13 years ago

This is a great library; I used it to build a Diffie-Hellman key exchange and symmetric encryption in an ASP.NET MVC4 app. The result is horribly insecure, but there is a situation where our product is installed under Http rather than Https that I solved.

If anyone is curious, it works just fine with BouncyCastle and RFC2989DeriveBytes (for PBKDF2).

Stanford Javascript Crypto Library

Related Stories