- cypherpunks - lists.cpunks.org

NSA Systems Abroad Query
by John Young 28 Jul '14

28 Jul '14

What is NSA "WB Quad System" for GCHQ, Amberwind (PL), TIGERFIRE (IN), IBIS (AU, JP), GCSB SSO Site (NZ): <http://t.co/AoBG9jyuAY>http://cryptome.org/2014/07/nsa-fy13-semiannual-report.pdf This is an NSA travel expenses report. Via Jason Leopold.

2 1

Russia open procurement for report on deanonymization of Tor users
by Anton Nesterov 28 Jul '14

28 Jul '14

It's tender by "Special equipment and communication of Ministry of Internal Affairs". Title fully says "Study the possibility of obtaining technical information about users (user equipment) on anonymous network Tor, codename TOR (navy)" ~$111500 (3 900 000 roubles) http://zakupki.gov.ru/epz/order/notice/zkk44/view/common-info.html?regNumbe…

4 3

Re: [tor-talk] EFF / applied law mailing list?
by Zenaan Harkness 28 Jul '14

28 Jul '14

Eben's emails get rejected from at least one of these lists. If there is a whitelist facility, his email addy ought definitely be on it. On 7/28/14, Eben Moglen <moglen(a)columbia.edu> wrote: > Yes, but please be careful that people don't rely on the conversation > as legal advice. That should be printed in the footer of every > message that goes through the system: This isn't legal advice, you > can't rely on it. If you have questions, get local legal help AND > etc.

1 0

Fwd: [Cryptography] hard to trust all those root CAs
by grarpamp 27 Jul '14

27 Jul '14

---------- Forwarded message ---------- From: Caspar Bowden (lists) <lists(a)casparbowden.net> Date: Sun, Jul 27, 2014 at 2:21 PM Subject: Re: [Cryptography] hard to trust all those root CAs To: Peter Gutmann <pgut001(a)cs.auckland.ac.nz>, crypto.jmk(a)gmail.com, justgold79(a)gmail.com Cc: cryptography(a)metzdowd.com On 07/25/14 06:13, Peter Gutmann wrote: John Kelsey <crypto.jmk(a)gmail.com> writes: Yeah, and the judge and prosecutor who get your case will be helpless before your clever skills at evading them, because they've never had to deal with literal-minded people trying transparent dodges to get around the law before. You will doubtless enjoy the same success as tax protesters do when they end up in court. And shortly thereafter, you'll enjoy an all-expenses- paid vacation with free room and board, courtesy of the US government. This should be preserved somewhere as the standard response to the Rumpelstiltskin Defence ("you can't prove I'm using crypto/know the keys so you'll have to let me go"). This perfectly sums up what will happen to anyone who wants to try the Rumpelstiltskin Defence in court. In UK law, there is a Rumpelstiltskin Defence (and although I am not happy with the result, I caused it to be put there and it is better than nothing) http://www.theyworkforyou.com/lords/?id=2000-06-28a.1006.27#g1007.6 (that's all there is BTW - not aware of anything worthwhile written since, grateful for any refs or cases) see also www.fipr.org/sfs8/bowden.pdf Caspar Bowden _______________________________________________ The cryptography mailing list cryptography(a)metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography

1 0

Re: [Cryptography] Browser JS (client side) crypto FUD
by grarpamp 27 Jul '14

27 Jul '14

On Sat, Jul 26, 2014 at 2:57 PM, Theodore Ts'o <tytso(a)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/

1 0

Re: [Cryptography] propaganda on "hurdles for law enforcement"
by grarpamp 27 Jul '14

27 Jul '14

On Sun, Jul 27, 2014 at 12:42 PM, Benjamin Kreuter <brk7bx(a)virginia.edu> wrote: > That is probably not going to work. Suppose we lived in such a world > and the government established a "lawful intercept requirement." Ten > years later all the newest software and devices on the market would have > back doors, and only a small group of hackers and activists would be > using good crypto. Even that small group would have to use the > backdoor'd products for day-to-day things like banking. It's about entrenching good crypto and its benefits *before* govt's can react without needing to expend extra effort to rip out said entrenchment. > The government has a lot of experience with phasing out products, even > when it requires coordinating individual households. Analog TV is gone > despite the proliferation of analog receivers. Tetraethyl lead is only > used for niche purposes like aviation, despite the fact that once upon a > time people drive cars designed for leaded fuel. The government could > treat cryptography the same way if it wished. HD was better and opened spectrum, so people didn't rise against buying new TV's, especially for smaller cheaper LED vs CRT. Health was better and cars rusty, so people didn't rise against new cars, especially for cheaper and more fuel economy. Gov't wins when they offer something people want. The sooner you entrench something they want... crypto protection from 'the spies'... the sooner gov't will have a very hard time taking it away. Crypto is like candy to a world of newspawn Snowden babies... hard to pull once given. So start giving it away... https://www.prism-break.org/ > Here in the USA people are convinced that dangerous > criminals are lurking behind every corner Take those cowards you know out to the gun range and show them how to fix their house and cars. Man them up out of irrational fear and into confidence. People are pumped full of FUD, hard to combat directly, so tricky end arounds are needed. Anonymously pamphlet your workplace with EFF. > The importance of privacy and related civil rights are hard to explain > to people who never lived under the Stasi or the Securitate. Apparently Zuckerberg, Saverin, Moskovitz, Sandberg and others of Jewish heritage behind Facebook have forgotten what collecting, processing and benefiting from data on users can turn into. As ones who should know, why are they collecting and not out there 'explaining'? > the NSA. Again, hard to combat. Make it real for them... everything they do is collected, stored, watched... convos, pics, mail, a life of their expressed thoughts... without their consent, forever. Count the cameras on your ride home from work, the junkmail in your post, the ads in your browser. > You should write to your representatives, because that is part of the > power you have. It's also relatively easy to stop by local party offices and ask 'Hey, what are you guys doing about all this spying stuff?'. Presenting issues in person is hard to ignore, I've had good experiences with local official types.

1 0

Re: Russia open procurement for report on deanonymization of Tor users
by Anton Nesterov 27 Jul '14

27 Jul '14

Troy Benjegerdes wrote: > On Thu, Jul 24, 2014 at 02:15:15PM +0000, Anton Nesterov wrote: >> It's tender by "Special equipment and communication of Ministry of >> Internal Affairs". Title fully says "Study the possibility of obtaining >> technical information about users (user equipment) on anonymous network >> Tor, codename TOR (navy)" >> >> ~$111500 (3 900 000 roubles) >> >> http://zakupki.gov.ru/epz/order/notice/zkk44/view/common-info.html?regNumbe… > > Here's some press about it. > > http://www.digitaltrends.com/computing/russia-announces-111000-bounty-ident… > > I find two things particularly amusing. > > 1) that russian companies and citizens would have to pay an entry fee It's normal, almost all Russian procurements are like this. Also, it can be only companies that have licenses for access to classified information and for producing wiretapping devices, I'm not sure it can be citizens. Probably it will be some companies like MFI Soft or Norsi Trans who already produce devices Russian mass-surveillance program SORM. There is something more about that companies https://www.privacyinternational.org/blog/lawful-interception-the-russian-a… > 2) CMU dropped their blackhat presenation > https://www.blackhat.com/latestintel/07212014-a-schedule-update.html > > How likely is it the NSA decided to embargoed CMU's presentation so they > could keep the data flowing out of Russia via Tor, or does CMU just have > a russian company they are going to 'license' this too? Not very likely. I don't think break Tor costs just $111,500. It seems more like report on existing weaknesses. Also, Russian journalists found some more interesting procurements published same day by same agency, including tender for trojan ( http://zakupki.gov.ru/epz/order/notice/zkk44/view/common-info.html?regNumbe… ).

1 0

EFF / applied law mailing list?
by grarpamp 27 Jul '14

27 Jul '14

Is there such thing as an applied law / best practices mailing list in the digital field... perhaps suited to service providers, but also covering users, and meta-orgs of digital/privacy/activism/rights, etc? And perhaps where real lawyers might actually participate in discussion.

4 5

Browser JS (client side) crypto FUD
by Lodewijk andré de la porte 26 Jul '14

26 Jul '14

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.

2 1

HOPEx report: My panel surveilled, phone hacked
by Douglas Lucas 26 Jul '14

26 Jul '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi cypherpunks, I was a panelist on HOPE X's ProjectPM panel, which discussed crowdsourcing research into private surveillance contractors like Palantir, HBGary, Stratfor...and it appears some of those (Stratfor?) came to record our panel. There's also what happened to my phone. All of this is written up in my HOPEx report, which y'all might find interesting: http://thecryptosphere.com/2014/07/23/report-from-hope-x-surveillance-snowd… Thanks, Douglas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJT0UlqAAoJEC+clbKIC3FxAY8P/266ajSxOjPAoFd5Jve5Bd1J HqSBzjO0DLU9kDXIw0s1qxxpj5owwHMdG6K7gzcpmIqc+WU80TOUC96EYCC+fyoT kU3DHvU1RC8VVR+6WS+y5Hn4sxkudiqumFaT8iaY5gePLQUaAvlTxy65FoydHH4I sB7+1wJVamIlygw3qgUMX01N02hs6FTj6gFkd5ZpRlGTrM/1cVsIPr8dq9ySzCAZ MehsJG8rX1lAVSqu+dN6qdkhmXO2EmSAPxcWT+vxnnAOi+t1wWth5jizrwv7sNnv JyB0ItuwPH/JGl3KxWbic666HkUIZkYVTmbwm8fd+ZMZ8zgfEmrHLitnwtlJEe6K l79VDwE9HuyRs8dwBKX2S1AhwccOLmbtgviLWynheJ9uJM0kmx4OLWSGCg0BRioF dkZxxh5W0ocVY++iR4Nqh+aAco71PHgcFLbTSrGT8sePUJhtUEMDoRSIvYE4n+hK bUEzTypcOnKvOm3w6o1iQB6mDkhIwEKB7czRwJdUTYuukC3QwsJ33fUM+Tgxh1y+ G63/bY1QvOwaoskdKtZR10f3+1X4Mo7f9k8qhtcKsi8Pep8KcK5AHmI1bPlbqqkn D+rGm2U3/2chR/zGkQzlD0HuF1SMAMhJKOdol7aUnd4L3YG+sV20c9bpFvAQhhEn +FkTgGIoE/yVewHRtauU =2a9F -----END PGP SIGNATURE-----

3 4