Why JavaScript Crypto Is Useful(vnhacker.blogspot.com)
vnhacker.blogspot.com
Why JavaScript Crypto Is Useful
http://vnhacker.blogspot.com/2014/06/why-javascript-crypto-is-useful.html
3 comments
The main criticisms of JS crypto that I've seen have nothing to do with the language, just that it's in-browser scripting hosted by a third party. Even if the language were perfectly designed for cryptography, the problem is the trust model - every single time you decrypt or sign something, you need to load your private key (or give a password for key generation, or whatever) into the script, which means that you need to make sure that the code has not been subverted every single time, which is nearly impossible to do anyway. So if you try and offer a service that says, "Even I can't access your e-mails, they are end-to-end encrypted using Javascript in your browser!", that may be true right now, but you can revoke that trust unilaterally by changing the Javascript and I won't notice. You could be compelled to do this. Your server might be compromised in some way, then all of a sudden you've got my private key. The whole problem that end-to-end encryption solves is that the server/cloud can only say, "We won't look at your data.", not "We can't look at your data." If you're controlling the encryption process with javascript, then you can't necessarily decrypt the data when it's at rest, but the next time I log in, you could snatch my keys, and maybe you've already done that at some point. So now we're back to a "We won't look at your data." model, because you're just making the choice not to subvert the crypto javascript.
Think about what you'd do if you were going to install TrueCrypt or some other security/cryptography program. Assuming you didn't want to build it from the source, you'd download a binary, and that binary would have an SHA or MD5 hash next to it, verifying that it's the correct file. Other people who compile the binary from source should be able to generate the same file and compare the hashes, so at the very least it can be audited and you can verify that you've got what they say you have. To do the equivalent thing with in-browser Javascript, you'd need to check the MD5 hash of the javascript that you're executing every single time you use the script, BEFORE you start the encryption/decryption process. You could use some sort of browser extension to check that the script you're about to download and execute is the same one you've used before, but if you're already installing browser extensions to do something like that, you might as well just install a browser extension that does the crypto for you without having a trust relationship with a server.
Think about what you'd do if you were going to install TrueCrypt or some other security/cryptography program. Assuming you didn't want to build it from the source, you'd download a binary, and that binary would have an SHA or MD5 hash next to it, verifying that it's the correct file. Other people who compile the binary from source should be able to generate the same file and compare the hashes, so at the very least it can be audited and you can verify that you've got what they say you have. To do the equivalent thing with in-browser Javascript, you'd need to check the MD5 hash of the javascript that you're executing every single time you use the script, BEFORE you start the encryption/decryption process. You could use some sort of browser extension to check that the script you're about to download and execute is the same one you've used before, but if you're already installing browser extensions to do something like that, you might as well just install a browser extension that does the crypto for you without having a trust relationship with a server.
Example end-to-end encrypted chat I made using Dropbox as an encrypted data store:
https://diafygi.github.io/byoFS/examples/chat/
Would love feedback on it or the overall byoFS project.
https://diafygi.github.io/byoFS/examples/chat/
Would love feedback on it or the overall byoFS project.
This looks discussion worthy. I still suspect that it is rarely a good idea given all the injection opportunities (from sites where resources are loaded from, XSS or even browser plugins).
Yeah. The ability of Javascript to underpin a cryptographic system isn't a question. For some systems, where the code will never be transmitted to an executing system, no problems.
It's the transit that presents a vulnerability. If the cryptosystem can be intercepted and modified enroute to the host that will execute it, it cannot be considered secure. If the cryptosystem is delivered as part of an embedded system, it's more likely it can be considered secure.
edit: I'll add a caveat to the cannot. It's more reasonable to consider it secure if it sends a hashed checksum of itself to a server, using itself to generate the hash and it sends a copy of itself to the server to generate the hash. If the hashes match, it's quite likely good to go. The total transmission required for this style of code authentication is worth consideration.
It's the transit that presents a vulnerability. If the cryptosystem can be intercepted and modified enroute to the host that will execute it, it cannot be considered secure. If the cryptosystem is delivered as part of an embedded system, it's more likely it can be considered secure.
edit: I'll add a caveat to the cannot. It's more reasonable to consider it secure if it sends a hashed checksum of itself to a server, using itself to generate the hash and it sends a copy of itself to the server to generate the hash. If the hashes match, it's quite likely good to go. The total transmission required for this style of code authentication is worth consideration.
How would you know it sent the hash to the server? It would have to tell you, and if it were undermined, they would just say, "Yep, hash checks out!" You'd really need a browser extension or something installed locally that checks the code for you, in which case you might as well just install something that does proper end-to-end encryption anyway.
Yeah, you're onto something.
What about it hashes itself, sends the hash to the server through a tunnel generated by the questionable cryptosystem. If that checks out, the server sends back a more robust cryptosystem through the questionable tunnel.
But Then we're right back where we started. Is that questionable tunnel weak enough to be considered vulnerable?
End-to-end is more easily checked for security. To me, Javascript's good for an embedded system, no doubt about the possibility of a cryptosystem being implementable, but, it's difficult to consider it secure for many use cases.
What about it hashes itself, sends the hash to the server through a tunnel generated by the questionable cryptosystem. If that checks out, the server sends back a more robust cryptosystem through the questionable tunnel.
But Then we're right back where we started. Is that questionable tunnel weak enough to be considered vulnerable?
End-to-end is more easily checked for security. To me, Javascript's good for an embedded system, no doubt about the possibility of a cryptosystem being implementable, but, it's difficult to consider it secure for many use cases.
I want to introduce many useful applications of Javascript crypto that I've seen, and I want to explain that developing crypto in Javascript is difficult because of the lack of types. What I found surprisingly is that most people that complain about Javascript crypto don't even mention this problem. I guess they think the language is too bad to even give it a try.