http://matasano.com/articles/javascript-cryptography/
Is surprisingly often passed around as if it is the end-all to the idea of
client side JS crypto.
TL;DR: It's a fantastic load of horse crap, mixed in with some extremely
generalized cryptography issues that most people never thought about before
that do not harm JS crypto at all.
I'm not sure why the guy wrote it. Maybe he's NSA motivated? Maybe he's
worked a lot on secure systems and this just gives him the creeps? Maybe
he's the kind of guy that thinks dashJS/dash dynamic scripted languages
are not a real languages?
Somebody, please, give me something to say against people that claim JS
client side crypto can just never work!
-
Aside from that it's, well, fundamentally moronic to claim that something
is harmful when you actually means it does nothing, it's also just
(almost!) never true that no attacks are prevented.
But, let's go with the flow of the article. Rants won't really settle
arguments.
Two example usages are given.
The first is client-side hashing of a password, so that it's never sent in
the clear. This is so legitimate it nearly makes me drop my hat, but, the
author decides to use HMAC-SHA1 instead of SHA2 for reasons that are fully
beyond me. Perhaps just trying to make things less secure?
The second is using AES keys to client side encrypt. The author must've
thought he was being helpful when he imagined the scheme for this. Or maybe
he was drunk. So you generate an AES key for each note, send it to the
user's browser to store locally, forget the key, and let the user wrap and
unwrap their data.. Somehow trusting the transport layer is all back in
vogue. The only key-generation problem in JS is entropy, which is a problem
everywhere tbh. If you really want to ensure entropy, send a random data
blob and XOR it with whatever client-side best-shot at randomness.
Whatever.
The author bluntheadedly claims They will both fail to secure users. In
principle I agree, his methods sucked balls. He, however, blames it on JS.
Okay.. Let's go on.
REALLY? WHY?
For several reasons, including the following:
1 Secure delivery of Javascript to browsers is a chicken-egg problem.
2 Browser Javascript is hostile to cryptography.
3 The view-source transparency of Javascript is illusory.
Until those problems are fixed, Javascript isn't a serious crypto research
environment, and suffers for it.
(points numbered for pointwise addressing)
1 - Yeah. Duh. What do you think of delivering anything client side?
There's the whole SSL infrastructure, if that doesn't cut it for you, well,
welcome to the Internet. (I suggest the next article is about how the
Internet is fundamentally flawed.) I would suggest, however, that once your
delivery pathway is exploited you're fundamentally screwed in every way.
You can't communicate anything, you can't authenticate anyone, you really
can't *do* anything! So let's leave out the Javascript part of this
point, and just do whatever we're already doing to alleviate this issue.
2 - This is a conclusion without any basis so far (aside from being..
meaningless to a computer scientist. Hostile?)
3 - Then just look at what data was transferred. Does every crypto
application require checkable source? Is any SSL implementation considered
harmful because nobody is able to flawlessly read the code, no compilers
are trusted, etc?
Okay so that chapter meant absolutely nothing. The author goes on to try to
defend his brabble:
WHAT'S THE CHICKEN-EGG PROBLEM WITH DELIVERING JAVASCRIPT CRYPTOGRAPHY?
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. The same attacker who was sniffing passwords or reading
diaries before you introduce crypto is simply hijacking crypto code after
you do.
A fair point against a single thread model. Interestingly the last line
does absolutely not have to hold, sniffing (after the fact) and on-the-fly
rewriting are worlds apart. Take Tempest of Xkeyscore, for example, they
can't do rewrites. They need specialized programs for that. (Conclusion:
nope, nothing to see here)
The next chapter tries to justify the fallacies made earlier on. Equating a
rewrite to a read, ad-homineming the JS crypto industry (and failing to
distinguish operational security from actual security), and lastly claiming
that misplaced trust is bad (which is obvious and unrelated).
The next chapter claims SSL is safe, and real crypto unlike JS crypto.
Then firmly cements his baseless ridicule by claiming that if you use
non-JS crypto to make JS crypto work, then obviously there's no point.
The next chapter WHAT'S HARD ABOUT DEPLOYING JAVASCRIPT CRYPTO CODE OVER
SSL/TLS? claims all the page has to be SSL/TLS and that makes it hard.
It's not hard and you should already be doing it to have /*any*/ security.
Not to mention it's not true, only that interpreted as
