Universities should do more open source projects. How about a university that funds open source works exclusively?
Stanford Javascript Crypto Library
11–20 of 91 posts
Re: Stanford Javascript Crypto Library
#12Relatedly, 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?
Re: Stanford Javascript Crypto Library
#13Great. Now can we see more services implement easy to use client-side encryption before uploading data to their servers?
Re: Stanford Javascript Crypto Library
#14Great. Now can we see more services implement easy to use client-side encryption before uploading data to their servers?
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.
Re: Stanford Javascript Crypto Library
#15Universities 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.
Re: Stanford Javascript Crypto Library
#16With 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.
Re: Stanford Javascript Crypto Library
#17With 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…
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.
Re: Stanford Javascript Crypto Library
#18Obligatory 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…
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.
Re: Stanford Javascript Crypto Library
#19Great. Now can we see more services implement easy to use client-side encryption before uploading data to their servers?
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.
Re: Stanford Javascript Crypto Library
#20Anyone 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.