On 7/26/2014 11:03 AM, Lodewijk andré de la porte wrote:
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 <dash>JS</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 page
contents has to be SSL'ed (eg, images don't need to be transported
over SSL).
So, point 1 has no merit against JS whatsoever. There's also a lot of
FUD-like text that denies reality. Especially the assumption that SSL
and desktop programs are somehow more secure.
So point 2.
(letterized for pointwise addressing)
"HOW ARE BROWSERS HOSTILE TO CRYPTOGRAPHY?
In a dispriting variety of ways, among them:
a - The prevalence of content-controlled code.
b - The malleability of the Javascript runtime.
c - The lack of systems programming primitives needed to implement crypto.
d - The crushing weight of the installed base of users.
Each of these issues creates security gaps that are fatal to secure
crypto. Attackers will exploit them to defeat systems that should
otherwise be secure. There may be no way to address them without
fixing browsers."
a, c, d are, at first sight, all rubbish. b is a very genuine point
however. With prototyping and the like it can be VERY hard to see
what's going on. It's an often mentioned thing about JS that it's too
powerful in some ways, and it can be true. The same goes for C and
memory control.
Next chapter confirms that a is rubbish.
Chapter after that explains some basic Comp Sci about when you can
trust something (and discredits something that can help in a lot of
cases, any if you do it correctly (which is too hard))
Chapter after that rehashes the idea that you can't trust the
environment unless you trust the whole environment, which is also the
same everywhere. (I also refer to trusting the compiler)
Next chapter is titled "WELL THEN, COULDN'T I WRITE A SIMPLE BROWSER
EXTENSION THAT WOULD ALLOW JAVASCRIPT TO VERIFY ITSELF?". And guess
what, the author agrees. You can indeed do this. If you're just doing
it for yourself or a single kind of crypto you could also make a
plugin for that. Which is what the WhatWG is doing with the HTML5
crypto extension. Then claims crypto is to PGP as programming
languages are to Lisp, which is rubbish.
The author then goes on to actually talk about random generators.
Which are not always required, but who cares, right? Then Secure
erase, which is only important if you expect the client device to be
exploited. Then ?timing attacks? which is even more specific and can
be alleviated easily enough.
Then tries to generalize his claim to remove JS specifically from the
equation, removing is last viable (but not definitive) arguments.
Some hating on key management, which is justified but again bullocks
wrt the main argument. (not to mention it's a problem everywhere, and
it can be solved like everywhere)
Some hate on people running old browsers, which has actually been
solved by background-auto-updating by now. (huzzah for all the added
insecurity there)
Then something about graceful degrading. Which is fair except for him
not sufficiently providing any reason JS crypto never works. (and not
relevant). He apparently meant this with d. Depends greatly on the
deployment situation, but in general it's FUD.
"AND WHEN YOU SAID "VIEW-SOURCE TRANSPARENCY WAS ILLUSORY"?
We meant that you can't just look at a Javascript file and know that
it's secure, even in the vanishingly unlikely event that you were a
skilled cryptographer, because of all the reasons we just cited."
Yeah. Welcome to programming. There's absolutely no truth to this
claim btw. Vagely referring to a large body of rubbish is not an argument.
The rest does not even try to take a direct shot anymore. Something
about how users that use 100 programs are more likely to find an
insecure one than people that use only 2 or 3.
He's the kind of guy that claims cracking and rewriting SSL
connections is easy, whereas using AES for a secure "cryptosystem" is
hard. I don't know what's up with this guy.
_______________________________________________
cryptography mailing list
[email protected]
http://lists.randombit.net/mailman/listinfo/cryptography
Okay, I read this article with a mixture of emotions. On one hand, yes,
crypto.js is weak. On the other hand, I tend to look at the glass as
half full when it comes to the future of tech. Yes, that includes
cryptography! Call me crazy, but I don't think JavaScript cryptography
is beat yet.
--
Kevin
_______________________________________________
cryptography mailing list
[email protected]
http://lists.randombit.net/mailman/listinfo/cryptography
