

Why JavaScript Crypto Is Useful - eugeneionesco
http://vnhacker.blogspot.com/2014/06/why-javascript-crypto-is-useful.html

======
cryptbe
Thanks for posting this article. I wrote it was a response to the Matasano's
article that I saw on Hacker News a few days ago.

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.

~~~
x1798DE
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.

------
diafygi
Example end-to-end encrypted chat I made using Dropbox as an encrypted data
store:

[https://diafygi.github.io/byoFS/examples/chat/](https://diafygi.github.io/byoFS/examples/chat/)

Would love feedback on it or the overall byoFS project.

------
josephlord
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).

~~~
aResponder23
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.

~~~
x1798DE
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.

~~~
aResponder23
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.

