- cypherpunks - lists.cpunks.org

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

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

26 Jul '14

---------- Forwarded message ---------- From: John Gilmore <gnu(a)toad.com> Date: Thu, Jul 24, 2014 at 8:36 PM Subject: Re: [Cryptography] hard to trust all those root CAs To: John Kelsey <crypto.jmk(a)gmail.com> Cc: "justgold79(a)gmail.com" <justgold79(a)gmail.com>, "cryptography(a)metzdowd.com" <cryptography(a)metzdowd.com> > > For January, we have not received any Nation Security Letters this month. > > On the month you receive one, you stop putting such notices out, and sell t= > he now-useless business. > 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. NSL's don't involve a judge. Nor even a prosecutor. They are an investigative tactic, used by the FBI (or the FBI proxying for NSA), long before a prosecutor is usually involved. The more likely it is that you will disclose a government request for snitching on your customers, the less likely it is that that request will ever arrive. Shining sunlight on spook activities is the best way to make them crawl back into their hole. > 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. Chuckle chuckle, just like the headlines about marijuana reform for decades. First they laugh at you, etc. But the joke doesn't excuse the iron fist you are trying to invoke to influence people. Mr. Kelsey, you usually don't fall to this level of "be afraid, the [government] terrorists are coming" propaganda. Ladar Levison, Mr. Lavabit, the last guy to do exactly what was suggested, is still out walking the streets -- and starting new companies that offer to protect their customers from covert surveillance. As often occurs, the spooks were less interested in smashing a guy who's standing up for the rights of the public, than they were in preventing a detailed public airing of what they were up to when they ran into him. John _______________________________________________ The cryptography mailing list cryptography(a)metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography

2 1

The small print on france.fr
by Georgi Guninski 25 Jul '14

25 Jul '14

http://www.france.fr/en/terms-conditions.html Section: Hypertext links pointing to France.fr --- The France.fr site authorises the inclusion of hypertext links (including deep links) pointing to its pages. However, the France.fr site must be explicitly mentioned in the link's title. The SIG reserves the right to demand the deletion of a link that it thinks does not comply with the purpose or missions of the France.fr site, or, more generally, the ethics of a public portal. This authorisation is valid for any public or private site, with the exception of those publishing polemical, pornographic, anti-Semitic or xenophobic information or information that could offend the sensibilities of most people. --- Appears to me this is official french government site.

3 2

Market for secure systems, ICLOAK puts Nix/Tor/TBB/etc on USB raises $95k
by grarpamp 24 Jul '14

24 Jul '14

On Wed, Jul 23, 2014 at 6:09 PM, rysiek <rysiek(a)hackerspace.pl> wrote: > Dnia środa, 23 lipca 2014 17:24:22 grarpamp pisze: >> Snowden triggers flood of Crapware [was: Gruveo, more secure skype?] I'll fork this one off to the Tor folks... > Here, have a chuckle: > https://www.kickstarter.com/projects/icloak/icloak-tm-stik-easy-powerful-on… > > Hat-tip to all the TAILS/Tor people here. https://icloak.org/ At least it appears from the splashpage to be an open bundling of mostly open tools that are thought reasonably well of, ie: Nix, Tor, GnuPG. As opposed to being some new unheard of closed commercialware. Things like this could serve by dropping more 'crypto by default' on the net at the end user level (even if such users are their own newbie cannon fodder on a learning curve). And spreading Unix also helps shift marketshare and knowledge away from Windows long term. If my two minute read of this one is right, it would be hard to not give them some kudos. I don't know what amounts are typically fundraised and the donor counts, but $95k for something like this seems to indicate a demand for more secure/private systems in general. Maybe a million will sell and send some donations back.

2 1

Streisand: Silence censorship. Automate the effect.
by rysiek 24 Jul '14

24 Jul '14

So, this has been floating in my vincinity lately: https://github.com/jlund/streisand Wonder what you wonderful people think of it. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - The Internet can be a little unfair. It's way too easy for ISPs, telecoms, politicians, and corporations to block access to the sites and information that you care about. But breaking through these restrictions is tough. Or is it? Introducing Streisand A single command sets up a brand new server running a wide variety of anti-censorship software that can completely mask and encrypt all of your Internet traffic. Streisand natively supports the creation of new servers at Amazon EC2, DigitalOcean, Linode, and Rackspace—with more providers coming soon! It also runs on any Debian 7 server regardless of provider, and hundreds of instances can be configured simultaneously using this method. The process is completely automated and only takes about ten minutes, which is pretty awesome when you consider that it would require the average system administrator several days of frustration to set up even a small subset of what Streisand offers in its out-of-the-box configuration. Once your Streisand server is running, you can give the custom connection instructions to friends, family members, and fellow activists. The connection instructions contain an embedded copy of the server's unique SSL certificate, so you only have to send them a single file. Each server is entirely self-contained and comes with absolutely everything that users need to get started, including cryptographically verified mirrors of all common clients. This renders any attempted censorship of default download locations completely ineffective. But wait, there's more... More Features Nginx powers a password-protected and encrypted Gateway that serves as the starting point for new users. The Gateway is accessible over SSL, or as a Tor hidden service. Beautiful, custom, step-by-step client configuration instructions are generated for each new server that Streisand creates. Users can quickly access these instructions through any web browser. The instructions are responsive and look fantastic on mobile phones: Streisand Screenshot The integrity of mirrored software is ensured using SHA-256 checksums, or by verifying GPG signatures if the project provides them. This protects users from downloading corrupted files. All ancillary files, such as OpenVPN configuration profiles, are also available via the Gateway. Current Tor users can take advantage of the additional services Streisand sets up in order to transfer large files or to handle other traffic (e.g. BitTorrent) that isn't appropriate for the Tor network. A unique password, SSL certificate, and SSL private key are generated for each Streisand Gateway. The Gateway instructions and certificate are transferred via SSH at the conclusion of Streisand's execution. Distinct services and multiple daemons provide an enormous amount of flexibility. If one connection method gets blocked there are numerous options available, most of which are resistant to Deep Packet Inspection. All of the connection methods (including L2TP/IPsec and direct OpenVPN connections) are effective against the type of blocking Turkey has been experimenting with. OpenSSH, OpenVPN (wrapped in stunnel), Shadowsocks, and Tor (with obfsproxy and the obfs3 or ScrambleSuit pluggable transports) are all currently effective against China's Great Firewall. Every task has been thoroughly documented and given a detailed description. Streisand is simultaneously the most complete HOWTO in existence for the setup of all of the software it installs, and also the antidote for ever having to do any of this by hand again. All software runs on ports that have been deliberately chosen to make simplistic port blocking unrealistic without causing massive collateral damage. OpenVPN, for example, does not run on its default port of 1194, but instead uses port 636, the standard port for LDAP/SSL connections that are beloved by companies worldwide. L2TP/IPsec is a notable exception to this rule because the ports cannot be changed without breaking client compatibility The IP addresses of connecting clients are never logged. There's nothing to find if a server gets seized or shut down. Services Provided L2TP/IPsec using strongSwan and xl2tpd A randomly chosen pre-shared key and password are generated. Windows, OS X, Android, and iOS users can all connect using the native VPN support that is built into each operating system without installing any additional software. Streisand does not install L2TP/IPsec on Amazon EC2 servers by default because the instances cannot bind directly to their public IP addresses which makes IPsec routing nearly impossible. OpenSSH An unprivileged forwarding user and SSH keypair are generated for sshuttle and SOCKS capabilities. Windows and Android SSH tunnels are also supported, and a copy of the keypair is exported in the .ppk format that PuTTY requires. Tinyproxy is installed and bound to localhost. It can be accessed over an SSH tunnel by programs that do not natively support SOCKS and that require an HTTP proxy, such as Twitter for Android. OpenVPN Self-contained "unified" .ovpn profiles are generated for easy client configuration using only a single file. Multiple clients can easily share the same certificates and keys, but five separate sets are generated by default. Client DNS resolution is handled via Dnsmasq to prevent DNS leaks. TLS Authentication is enabled which helps protect against active probing attacks. Traffic that does not have the proper HMAC is simply dropped. The Dante proxy server is set up as a workaround for a bug in Firefox for Android. Shadowsocks A QR code is generated that can be used to automatically configure the Android and iOS clients by simply taking a picture. You can tag '8.8.8.8' on that concrete wall, or you can glue the Shadowsocks instructions and some QR codes to it instead! Stunnel Listens for and wraps OpenVPN connections. This makes them look like standard SSL traffic and allows OpenVPN clients to successfully establish tunnels even in the presence of Deep Packet Inspection. Unified profiles for stunnel-wrapped OpenVPN connections are generated alongside the direct connection profiles. Detailed instructions are also generated. The stunnel certificate and key are exported in PKCS #12 format so they are compatible with other SSL tunneling applications. Notably, this enables OpenVPN for Android to tunnel its traffic through SSLDroid. OpenVPN in China on a mobile device? Yes! Tor A bridge relay is set up with a random nickname. Obfsproxy is installed and configured, including support for the obfs3 and ScrambleSuit pluggable transports. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -- Pozdr rysiek

1 0

Snowden triggers flood of Crapware [was: Gruveo, more secure skype?]
by grarpamp 24 Jul '14

24 Jul '14

On Wed, Jul 23, 2014 at 2:29 PM, Cypher <cypher(a)cpunk.us> wrote: > On 2014-07-22 23:24, unixninja92 wrote: >> >> Recently found Gruveo[1]. Allows easy video and audio calls similar to >> cryptocat. Unfortunately not open source and makes no mention of being >> audited. Otherwise looks very interesting and promising. It tries to >> use P2P to make calls, and if it fails, then it will go through their >> servers. Uses WebRTC for end to end encrypted audio and video chat. >> They claim they don't keep any logs that could identify users. >> >> So the question is, is this an NSA honey pot or something that might >> actually be trustworthy? It seems at least a bit more >> secure/trustworthy than skype to me. > > > Why even consider closed alternatives when you have things like Jitsi[1] > available? It's open source, does secure voice, video, and text, and runs on > just about any platform (including Android). > > [1] www.jitsi.org > Eugen says... > RetroShare has quite good P2P audio. It's not properly audited though, > caveat emptor. Ditto. Though it will take some time not just for the open source community to pick which projects to audit under limited resources, but to even develop a real auditing framework within itself to do that under. It's a huge undertaking and responsibility in its own right. Further, what's with crap like gruveo.com, goldbug.sf.net [1], protonmail.ch, and so many more (especially the 'Look, we just solved Email encryption' crowd)? And of the partly open hw/sw stack vendor types like BlackPhone? What are we, some free debunkment service for shills, charlatans, closed source, browser/app/phone loaded crypto/exec environments provided by the service provider instead of reasonably disinterested third parties, keys disclosed, Web3.0, looks like a phone, junk? Sure, ok, it's good that we are, but the dearth of CrapWare and ProCrap analysts and marketers popping up out there lately is ridiculous. And I'm not laying down a universal CrapWare blanket, some of the stuff we see is pretty good, but simply fails to clearly, publicly, and obviously state to its users what risks their model does not cover. That's lack of care, obliviousness, lying, or profiteering... so it lands itself back in Crap territory. To quote OP... not open source.. not audited.. central servers.. webrtc.. 'no' logs.. and a shiny link for grins... and then claims it 'looks very interesting and promising'. WTF, really? I appreciate innocent questions, but the answer (or at least our response) should be obvious, from those parameters alone, to someone who's been around for a while. Though the makeup of their lists is perhaps not yet complete/ideal, you'd be better off picking anything from prism-break.org, yes say Jitsi, than this type of Crapware. We should make prism-locked.org just to list all the junk out there. It's good to have more crypto used in the world, but let's at least try to make and promote strong and open solutions. [1] I and others have been displeased with their, shall we say, 'community involvement'. As with the attempts at parallel compilation and auditing of Truecrypt, has anyone attempted that with their code? Tried to contact them? Seen any presentations? Know who they are? Open development? Etc? People say OpenPGP and crypto is hard for user adoption, no gui's for grandma, etc. So when potentially interesting gui tools appear, it's a shame many of them choose to draw these questions and thus seriously limit and tarnish their forward prospectus. At least Gruveo appears to have already answered those questions.

9 22

Fwd: a catalog of bugs, or "Why to disable assembly optimization"
by coderman 24 Jul '14

24 Jul '14

---------- Forwarded message ---------- From: Zooko Wilcox-OHearn <zooko(a)leastauthority.com> Date: Tue, Jul 22, 2014 at 12:23 PM Subject: a catalog of bugs, or "Why to disable assembly optimization" Folks: We had already agreed to disable assembly optimizations in pycryptopp, because there seem to have been a lot of bugs in the optimized assembly code in the past, and because the added speed really makes no difference to our uses, as far as I know. However, in order to explain and justify to other people (e.g. Debian packagers) why we are doing this, and why they should consider doing the same thing themselves, I just read through the entire history of issues in pycryptopp and classified whether they were runtime errors (and therefore potential security bugs) or build-time errors (therefore probably not), and whether they would have been avoided if we had been disabling assembly optimizations all along. Here are the results. They clearly show that we should disable the optimized assembly! About half of all the security-threatening bugs we've had would never have been an issue if we'd avoided assembly from the beginning. By the way, in my opinion the author of Crypto++, Wei Dai, is an *exceptionally* skilled, careful, and experienced coder, and I would assume that if Crypto++ has had this many security-threatening bugs in its optimized assembly code, then other crypto libraries that also use optimized assembly code also have at least as many. Here's the ticket to track this issue: https://tahoe-lafs.org/trac/pycryptopp/ticket/85 bugs that cause run-time failures ================================= (These bugs are potential security issues.) * would have been avoided by DISABLE_ASM: - https://tahoe-lafs.org/trac/pycryptopp/ticket/24 - https://tahoe-lafs.org/trac/pycryptopp/ticket/31 - https://tahoe-lafs.org/trac/pycryptopp/ticket/45 (three *different* bugs in the assembly implementation) - https://tahoe-lafs.org/trac/pycryptopp/ticket/67 - https://tahoe-lafs.org/trac/pycryptopp/ticket/84 - https://tahoe-lafs.org/trac/pycryptopp/ticket/86 * unclear if it would have been avoided if we'd used DISABLE_ASM: - https://tahoe-lafs.org/trac/pycryptopp/ticket/65 * would not have been avoided by DISABLE_ASM: - https://tahoe-lafs.org/trac/pycryptopp/ticket/17 - https://tahoe-lafs.org/trac/pycryptopp/ticket/44 - https://tahoe-lafs.org/trac/pycryptopp/ticket/83 * would not have been avoided by DISABLE_ASM (but would have been avoided by using cffi instead of CPython API) - https://tahoe-lafs.org/trac/pycryptopp/ticket/19 - https://tahoe-lafs.org/trac/pycryptopp/ticket/70 - https://tahoe-lafs.org/trac/pycryptopp/ticket/80 * would have been avoided if we *didn't* use DISABLE_ASM! (A bug only in the non-ASM version!) - https://tahoe-lafs.org/trac/pycryptopp/ticket/66 bugs that cause deterministic build or compilation failures =========================================================== (These bugs are *typically* not potential security issues but they can be, and in any case they are engineering/deployment issues.) * would have been avoided by DISABLE_ASM: - https://tahoe-lafs.org/trac/pycryptopp/ticket/37 - https://tahoe-lafs.org/trac/pycryptopp/ticket/96 * would not have been avoided by DISABLE_ASM: - https://tahoe-lafs.org/trac/pycryptopp/ticket/22 - https://tahoe-lafs.org/trac/pycryptopp/ticket/23 - https://tahoe-lafs.org/trac/pycryptopp/ticket/32 - https://tahoe-lafs.org/trac/pycryptopp/ticket/39 - https://tahoe-lafs.org/trac/pycryptopp/ticket/62 - https://tahoe-lafs.org/trac/pycryptopp/ticket/77 - https://tahoe-lafs.org/trac/pycryptopp/ticket/78 -- Regards, Zooko Wilcox-O'Hearn Founder, CEO, and Customer Support Rep https://LeastAuthority.com Freedom matters.

2 1

Tails vulnerability specific to I2P, not Tor
by Eugen Leitl 24 Jul '14

24 Jul '14

http://blog.exodusintel.com/2014/07/23/silverbullets_and_fairytails/ SILVER BULLETS AND FAIRY TAILS Introduction This week we made mention on Twitter of a zero-day vulnerability we’ve unearthed that affects the popular Tails operating system. As the Tails website states: Tails is a live operating system, that you can start on almost any computer from a DVD, USB stick, or SD card. It aims at preserving your privacy and anonymity, and helps you to: use the Internet anonymously and circumvent censorship; all connections to the Internet are forced to go through the Tor network; leave no trace on the computer you are using unless you ask it explicitly; use state-of-the-art cryptographic tools to encrypt your files, emails and instant messaging.” This software was largely popularized due to the fact that it was used by whistleblower Edward Snowden. Since then, the OS has garnered much attention and use by a wide range of those seeking anonymity on the Internet. We publicized the fact that we’ve discovered these issues for a very simple reason: no user should put full trust into any particular security solution. By bringing to light the fact that we have found verifiable flaws in such a widely trusted piece of code, we hope to remind the Tails userbase that no software is infallible. Even when the issues we’ve found are fixed by the Tails team, the community should keep in mind that there are most certainly other flaws still present and likely known to others. Our customers use our information for both offensive and defensive purposes to better protect themselves and others. Providing a wide variety of exploit software we help penetration testers effectively test network security and incident response teams. One high profile example occurred last year when Facebook used a zero-day vulnerability to test their teams response to a zero-day attack. The information we provide is also leveraged in defensive purposes providing companies with well documented research for use in IDS and AV signatures for previously unknown threats. We at Exodus are able to do what many software projects cannot, perform security code audits and find exploitable vulnerabilities releasing them to the public. The Vulnerable Component The vulnerability we will be disclosing is specific to I2P. I2P currently boasts about 30,000 active peers. Since I2P has been bundled with Tails since version 0.7, Tails is by far the most widely adopted I2P usage. The I2P vulnerability works on default, fully patched installation of Tails. No settings or configurations need to be changed for the exploit to work. I2P is preconfigured so that all .i2p TLD sites are routed through the I2P network. At a high level I2P traffic is message based similar to IP packets. All communication is encrypted end to end with a total of four layers of encryption. I2P routers (end points) act as cryptographic identifiers, similar to a pair of public keys. I2P is a packet switched network, instead of circuit switched like Tor. This means transparent load balancing of packets across multiple peers. I2P is fully distributed with no centralized resources. There is no distinct separation of servers to nodes, this architecture helps eliminate single points of failure. Demonstration To lend credence to our claims we have created a video that demonstrates de-anonymizing a Tails user: TailsDeAnonymizationTailsDeAnonymization ► Timeline 0:00:00,000 –> 0:00:10,400: Demonstrating IP on listening server, Turning on listening server 0:00:19,000 –> 0:00:25,400: Tails user visiting website icanhazip.com which shows the anonymized IP address 0:00:36,000 –> 0:00:49,400: Showing that we’re indeed using the latest Tails build 1.1 0:00:50,000 –> 0:01:03,400: I2P address being resolved, proof of concept malicious payload being delivered 0:01:30,000 –> 0:01:40,400: Listening server retrieves the Tails user’s de-anonymized IP address (Austin RoadRunner ISP) Note on Disclosure Disclosure of vulnerabilities takes many forms, particularly their shape is adapted to the landscape that the platform is used upon. In the past at Exodus Intelligence, we’ve felt that significant vulnerabilities have been disregarded and have not had the requisite exposure. Through appropriate airing of the issue, we feel that users of such security platforms may come to understand the risks in base-level trust. Even further we hope to break the mold of unconditional trust in a platform. Users should question the tools they use, they should go even further to understand the underlying mechanisms that interlock to grant them security. It’s not enough to have faith upon security, rather to have an understanding of it. If the public thinks Exodus is one of a few entities finding bugs in software, they are grossly misinformed. As is the case with all vulnerabilities we report to vendors, we do not ask for any remuneration. All flaws that we give to vendors are given free of charge. All accusations of extortion perpetuated by those unfamiliar with our business model are completely unfounded. As of publication of this blog post the Tails team and the I2P team have both received all the relevant details and exploit code they require to remediate the vulnerabilities we’ve discovered. Recently a high profile talk on de-anonymization Tor users was pulled from Blackhat due to legal issues. Their talk outlined with a budget of $3000 with some powerful servers and multiple gigabit links they were able to de-anonymize hundreds of thousands of users in ‘a couple of months’. Exodus decided to pick up where this talk left off by letting the community know that there are many other vectors for de-anonymization. The vulnerability we have found is able to perform remote code execution with a specially crafted payload. This payload can be customized to unmask a user and show the public IP address in which the user connected from within ‘a couple of seconds’. Stay Tuned Part two of this blog post will present a technical discussion of the vulnerability. This will be posted once we have confirmed the vulnerabilities in I2P are patched and have been incorporated into Tails.

2 1

OT: List Archives
by grarpamp 24 Jul '14

24 Jul '14

Can mailman be configured to include the 'To:' and 'Cc:' addresses in the archive gz's? It would add some needed context when locally combining/splitting multiple lists for MUA use. And is there a way retrieve monthly attachment gz's without needing to fetch per attachment? Also, how is the 'since inception' archive project coming?

2 1