11 ms·
Stanford Javascript Crypto Library
- nsmartt 13y agoThis could lead to a rise in services offering client-side encryption. A 'better' homepage might help.
- lisper 13y agoAnyone who needs a "better" home page probably ought not to be using it.
- nsmartt 13y agoDevelopers 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 13y agoMega does something like this. Encryption is done client-side. https://en.wikipedia.org/wiki/Mega_(website)#Data_encryption https://en.wikipedia.org/wiki/Mega_(website)#Data_encryption
- meshko 13y agoObligatory quote from http://www.matasano.com/articles/javascript-cryptography/ 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.
- gcommer 13y agoYou may be interested in the defensive js (http://www.defensivejs.com/ 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/ http://xkcd.com/792/
- __alexs 13y ago> It also provides a verified crpyto library implementation. Verified by who?
- anon1385 13y 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/ 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
- marcopolo 13y agoIf 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 https://github.com/bitwiseshiftleft/sjcl/pull/89
- brador 13y agoUniversities should do more open source projects. How about a university that funds open source works exclusively?
- goldfeld 13y agoRelatedly, 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?
- methehack 13y agoI was thinking about this too -- but if they compromised your encryption JS couldn't they also compromise your checksum JS?
- devx 13y agoGreat. Now can we see more services implement easy to use client-side encryption before uploading data to their servers?
- tptacek 13y agoGreat. 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 13y agoSure! 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_b 13y agoWith 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/ 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.
- tptacek 13y agoI'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_b 13y 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).
- jonpaul 13y agoAnyone 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.
- tlrobinson 13y agoYes, however isn't this sort of what HTTPS is supposed to accomplish?
- jonpaul 13y agoNot 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.
- jonknee 13y agoIf the server is compromised you're SOL.
- jonpaul 13y agoExactly. That's why I'm advocating for a signed JavaScript/HTML/webapp standard of some sort.
- bradleyland 13y agoThat is not true if you're using code signing. If someone compromises the server, they can overwrite the files, but they cannot forge code signing without additional access to code signing private keys. Security is achieved through layers. No single layer can protect you from everything, but we lay down the gauntlet in the hopes that an attacker will encounter a road block that they cannot pass.
- methehack 13y agoWhat 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.
- tptacek 13y agoYou 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.
- methehack 13y agoWell, 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?
- Wilya 13y agoBecause if I own your server, I can set it up so that it serves the good file to your pingdom-like service, and corrupted files to everyone else. Or more realistically, I'd do something more targeted, like serving the bad files only to the ip block of my business competitors.
- sneak 13y agoYou can checksum the whole page, but any externally loaded JS can monkeypatch any other part. Use analytics? How about a payment widget? All of these can affect every part of the js environment, overwriting anything from jQuery to sjcl. Alternately, they could leave the crypto alone and just hook into keystroke handlers or the DOM and steal your plaintext that way. Also, some browsers will run JS from urls referenced in img tags as long as they are served with a text/javascript MIME type. It's far too big an attack surface.
- deleted 13y ago[deleted]
- justapor 13y agoIt's JavaScript, not Javascript..
- nly 13y agoThe W3C have a draft API for hosted JavaScript cryptography: http://www.w3.org/TR/WebCryptoAPI/ 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 https://github.com/Netflix/NfWebCrypto
- franze 13y agoi built Masel with it (as a demo for our local javascript meetup) i.e.: http://replycam.com/m/ http://replycam.com/m/ pretty much serverless encrypted message sharing. its MIT L. and unfinished https://github.com/franzenzenhofer/masel https://github.com/franzenzenhofer/masel
- RazerM 13y agoOff-topic, but 'masel' is the Scots word for 'myself'.
- franze 13y agoi named it after the jidish http://en.wikipedia.org/wiki/Mazel_tov 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/ http://xkcd.com/323/ )
- sneak 13y agoLet's all congratulate austengary on successfully trolling HN's star quarterback.
- leke 13y agoI 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 https://www.youtube.com/watch?v=3HlQJWXlknE
- yawgmoth 13y agoThis 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).