Re: [cryptography] [Cryptography] Browser JS (client side) crypto FUD
On Tue, Jul 29, 2014 at 6:53 AM, Lodewijk andré de la porte l...@odewijk.nl wrote: JavaScript cryptography is possible, there are usecases, and it is *definitely* *not *considered harmful by default. By default you aren't using HTTPS, HSTS, and CSP. Without these things, doing cryptography in a web page is most definitely harmful and insecure. -- Tony Arcieri ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] [Cryptography] Browser JS (client side) crypto FUD
On Sat, Jul 26, 2014 at 2:57 PM, Theodore Ts'o ty...@mit.edu wrote: On Sat, Jul 26, 2014 at 05:03:46PM +0200, Lodewijk andré de la porte wrote: WHAT'S THE CHICKEN-EGG PROBLEM WITH DELIVERING JAVASCRIPT CRYPTOGRAPHY? Somebody, please, give me something to say against people that claim JS client side crypto can just never work! // ianG // It's like opportunistic security.. // It specifically defeats mass surveillance... This is a valuable thing. Yes, it's nice and helps. It just needs to come with better disclaimers. Otherwise companies/providers that remain silent on their threat models do nothing but tarnish themselves amongst those that know better. Such silence could backfire. Whether they get used as an bad example in security presentations, or something happens to one or more of their users they effectively sold (or gave) snakeoil to. Like it or not, the vast majority of people are using some kind of web based e-mail, whether it's GMail or Yahoo Mail or Hotmail, or something else. Please provide link to your source that breaks down Email use by HTTP, IMAP/SMTP and legacy POP. And their crypted versions. I think it's a bit more complicated than you're making it out to be. Ultimately, the nearly all of the software that people run come from the network, at one time or another. Even if you are using gpg running on your linux laptop, where did you get your copy of gpg and the Linux OS? Odds are, you got it over the network. The problem is the context of where in the network you got the software from, and who you're using it with, and who you're trying to keep in the dark. If your first install or subsequent updates are from your mail, storage, or comms central service provider, etc... that's a major and direct conflict of your security interests. It's why Matasano objects. You don't download your OS from your adversary. On the other hand, if you obtain and use the code independantly of your provider, or the code creates a disinterested decentral P2P infrastructure (Freenet, etc)... then you're in a much better position. You've inserted a layer of independance/abstraction. Similar to installing gnupg to use independantly... https://openpgpjs.org/ http://code.google.com/p/crypto-js/ You should be able to download openpgp.js from the code distribution point, read any audits, check the sig, locally load and permanently lock it into your browser from your plugins directory. And then mail providers should develop a consistant RFC based API from which you interact with them so you don't have to download whatever blob they claim you need. Directly trusting codeloading works fine for internal corporate environments. But it's a really bad idea elsewhere. Examples of careful differences in security model... Holds the keys https://www.hushmail.com/ Provides the code https://encrypt.to/ https://www.bitaddress.org/ https://brainwallet.github.io/ Browser addon (likely dependant on provider webmail scraping 'API': remember attempts to scrape providers that did not offer IMAP/POP.) https://www.mailvelope.com/ Standalone webclient https://whiteout.io/technology.html https://www.mailpile.is/ https://github.com/pagekite/Mailpile Standalone UI https://www.enigmail.net/ ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Browser JS (client side) crypto FUD
[Note: Dropped cypherpunks list as I'm not subscribed to that list.] On Sat, Jul 26, 2014 at 11:03 AM, Lodewijk andré de la porte l...@odewijk.nl 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: I don't see how you claim that it was TL;DR, especially when you put in as much time as you apparently did in your almost blow-by-blow reply. It was a mere 9 pages if you printed it out and if had they used formatting for headers normally used when presenting white papers, I would guess it would come out no more than mere 5 or 6 pages. 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? Really? You're going to go there and imply he's an NSA shill? That's pretty unprofessional. Somebody, please, give me something to say against people that claim JS client side crypto can just never work! I can't do that, because I wouldn't claim that it can never work. I could see it being useful if used correctly in the right context, which I mean as using it as an approach to security-in-depth. But if one is referring to moving all the crypto to the client side, I think that would generally be a huge mistake. - 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? I think it more likely had do do with the prevalence of SHA1. When was this written anyway? The only date that I saw was 2008 in reference to the browser maturity, where it stated: Check back in 10 years when the majority of people aren't still running browsers from 2008. (Of course that's still largely true today and will remain so until all those unsupported WinXP systems get replaced.) So assume HMAC-SHA2 here if you like. I don't think that changes things much. But I think the reason for the HMAC was because you clearly want a keyed hash where you are hashing a nonce in the sort of challenge-response authN system that the author is describing. But if the goal is to build something like SRP, it would be much better to build that into the HTTP specification so that the browsers and web servers could support them directly similar to how the do with HTTP Digest Authentication. 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. Well, it's really more than that and the problem goes beyond just JS
[cryptography] Browser JS (client side) crypto FUD
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
Re: [cryptography] [Cryptography] Browser JS (client side) crypto FUD
On 26/07/2014 16:03 pm, Lodewijk andré de la porte wrote: http://matasano.com/articles/javascript-cryptography/ ... Somebody, please, give me something to say against people that claim JS client side crypto can just never work! It's like opportunistic security; it's the best you get in a crappy world for free. The author acknowledges that SSL/TLS is expensive and messy, the alternative to that for most purposes is no security at all. This gives something in the middle. It specifically defeats mass surveillance, that which used to be known as passive eavesdropping in the trade before the lingo reset of recent times. This is a valuable thing. iang ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Browser JS (client side) crypto FUD
On Sat, Jul 26, 2014 at 8:03 AM, Lodewijk andré de la porte l...@odewijk.nl wrote: 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. What's in the Matasano article is common sense advice. It may seem elementary for some. But you'd be surprised how many sites fit the pattern the Matasano post describes, arguing that they can provide *better* security by serving JavaScript crypto code over easily-MitMed plaintext HTTP. Here are a couple offenders... #3 Google search result for encrypted chat: http://www.chatcrypt.com/ Not popular by Google results, but a similarly silly effort: http://www.peersm.com/ -- Tony Arcieri ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
