- cypherpunks - lists.cpunks.org

NSA Laughs at PCs, Prefers Hacking Routers and Switches
by Eugen Leitl 04 Sep '13

04 Sep '13

http://www.wired.com/threatlevel/2013/09/nsa-router-hacking/ NSA Laughs at PCs, Prefers Hacking Routers and Switches BY KIM ZETTER09.04.136:30 AM Photo: Santiago Cabezas/Flickr The NSA runs a massive, full-time hacking operation targeting foreign systems, the latest leaks from Edward Snowden show. But unlike conventional cybercriminals, the agency is less interested in hacking PCs and Macs. Instead, America’s spooks have their eyes on the internet routers and switches that form the basic infrastructure of the net, and are largely overlooked as security vulnerabilities. Under a $652-million program codenamed “Genie,” U.S. intel agencies have hacked into foreign computers and networks to monitor communications crossing them and to establish control over them, according to a secret black budget document leaked to the Washington Post. U.S. intelligence agencies conducted 231 offensive cyber operations in 2011 to penetrate the computer networks of targets abroad. This included not only installing covert “implants” in foreign desktop computers but also on routers and firewalls — tens of thousands of machines every year in all. According to the Post, the government planned to expand the program to cover millions of additional foreign machines in the future and preferred hacking routers to individual PCs because it gave agencies access to data from entire networks of computers instead of just individual machines. Most of the hacks targeted the systems and communications of top adversaries like China, Russia, Iran and North Korea and included activities around nuclear proliferation. The NSA’s focus on routers highlights an often-overlooked attack vector with huge advantages for the intruder, says Marc Maiffret, chief technology officer at security firm Beyond Trust. Hacking routers is an ideal way for an intelligence or military agency to maintain a persistent hold on network traffic because the systems aren’t updated with new software very often or patched in the way that Windows and Linux systems are. “No one updates their routers,” he says. “If you think people are bad about patching Windows and Linux (which they are) then they are … horrible about updating their networking gear because it is too critical, and usually they don’t have redundancy to be able to do it properly.” He also notes that routers don’t have security software that can help detect a breach. “The challenge [with desktop systems] is that while antivirus don’t work well on your desktop, they at least do something [to detect attacks],” he says. “But you don’t even have an integrity check for the most part on routers and other such devices like IP cameras.” Hijacking routers and switches could allow the NSA to do more than just eavesdrop on all the communications crossing that equipment. It would also let them bring down networks or prevent certain communication, such as military orders, from getting through, though the Post story doesn’t report any such activities. With control of routers, the NSA could re-route traffic to a different location, or intelligence agencies could alter it for disinformation campaigns, such as planting information that would have a detrimental political effect or altering orders to re-route troops or supplies in a military operation. According to the budget document, the CIA’s Tailored Access Programs and NSA’s software engineers possess “templates” for breaking into common brands and models of routers, switches and firewalls. The article doesn’t say it, but this would likely involve pre-written scripts or backdoor tools and root kits for attacking known but unpatched vulnerabilities in these systems, as well as for attacking zero-day vulnerabilities that are yet unknown to the vendor and customers. “[Router software is] just an operating system and can be hacked just as Windows or Linux would be hacked,” Maiffret says. “They’ve tried to harden them a little bit more [than these other systems], but for folks at a place like the NSA or any other major government intelligence agency, it’s pretty standard fare of having a ready-to-go backdoor for your [off-the-shelf] Cisco or Juniper models.” Not all of the activity mentioned in the budget document involved remote hacking. In some cases, according to the document, the operations involved clandestine activity by the CIA or military intelligence units to “physically place hardware implants or software modifications” to aid the spying. “Much more often, an implant is coded entirely in software by an NSA group called Tailored Access Operations (TAO),” the Post writes in its story about the document. “As its name suggests, TAO builds attack tools that are custom-fitted to their targets.” A handful of security researchers have uncovered vulnerabilities in routers in recent years that could be used to do the kind of hacking described in the budget document. In 2005, security researcher Mike Lynn found a serious vulnerability in Cisco IOS, the operating system running on millions of Cisco routers around the world. Lynn discovered the vulnerability after his employer, Internet Security Systems, asked him to reverse-engineer the Cisco operating system to see if he could find security problems with it. Cisco makes the majority of the routers that operate the backbone of the internet as well as many company networks and critical infrastructure systems. The Cisco IOS is as ubiquitous in the backbone as the Windows operating system is on desktops. The vulnerability Lynn found, in a new version of the operation system that Cisco planned to release at the time, would have allowed someone to create a router worm that would shut down every Cisco router through which it passed, bringing down a nation’s critical infrastructure. It also would have allowed an attacker to gain complete control of the router to sniff all traffic passing through a network in order to read, record or alter it, or simply prevent traffic from reaching its recipient. Once Lynn found the vulnerability, it took him six months to develop a working exploit to attack it. Lynn had planned to discuss the vulnerability at the Black Hat security conference in Las Vegas, until Cisco intervened and forced him to pull the talk under threat of a lawsuit. But if Lynn knew about the vulnerability, there were likely others who did as well — including intelligence agencies and criminal hackers. Source code for Cisco’s IOS has been stolen at least twice, either by entities who were interested in studying the software to gain a competitive advantage or to uncover vulnerabilities that would allow someone to hack or control them. Other researchers have uncovered different vulnerabilities in other Cisco routers that are commonly used in small businesses and home offices. Every year at computer security conferences — including the Black Hat conference where NSA Director Keith Alexander presented a keynote this year — U.S. intelligence agencies and contractors from around the world attend to discover information about new vulnerabilities that might be exploited and to hire talented researchers and hackers capable of finding more vulnerabilities in systems. In 2008, a researcher at Core Security Technologies developed a root kit for the Cisco IOS that was designed to give an attacker a persistent foothold on a Cisco router while remaining undetected. According to the Post story, the NSA designs most of the offensive tools it uses in its Genie operation, but it spent $25.1 million in one year for “additional covert purchases of software vulnerabilities” from private malware vendors who operate on the grey market — closed markets that peddle vulnerabilities and exploits to law enforcement and intelligence agencies, as opposed to the black market that sells them to cyber criminals. The price of vulnerabilities and exploits varies, depending on a number of factors. Vulnerabilities and exploits can sell for anywhere from $50,000 to more than a million, depending on the exclusivity of the purchase — some vulnerabilities are sold to multiple parties with the understanding that others are using it as well — and their ubiquity. A vulnerability that exists in multiple versions of an operating system is more valuable than a vulnerability that exists in just one version. A class of vulnerability that crosses multiple browser brands is also more valuable than a single vulnerability that just affects the Safari browser or Chrome. The Stuxnet cyber weapon that was reportedly created by the U.S. and Israel to sabotage centrifuges used in Iran’s uranium enrichment program, used five zero-day exploits to spread itself among systems in Iran, including a rare exploit that attacked the .LNK function in multiple versions of the Windows operating system in order to spread the worm silently via infected USB sticks. Ubiquitous router vulnerabilities are difficult to find since there are so many different configurations for routers, and an attack that works against one router configuration might not work for another. But a vulnerability that affects the core operating system is much more valuable since it is less likely to be dependent on the configuration. Maiffret says there hasn’t been a lot of public research on router vulnerabilities, but whenever someone has taken a look at them, they have found security holes in them. “They’re always successful in finding something,” he says. Once a vulnerability becomes known to the software maker and is patched, it loses a lot of its value. But because many users and administrators do not patch their systems, some vulnerabilities can be used effectively for years, even after a patch is available. The Conficker worm, for example, continued to infect millions of computers long after Microsoft released a patch that should have stopped the worm from spreading. Routers in particular often remain unpatched because system administrators don’t think they will be targeted and because administrators are concerned about network outages that could occur while the patch is applied or if the patch is faulty. Kim Zetter is a senior reporter at Wired covering cybercrime, privacy, security and civil liberties. Read more by Kim Zetter Follow @KimZetter and @ThreatLevel on Twitter.

2 1

Re: [tor-talk] Exit node stats collection?
by Eugen Leitl 04 Sep '13

04 Sep '13

----- Forwarded message from The Doctor <drwho(a)virtadpt.net> ----- Date: Wed, 04 Sep 2013 13:14:35 -0400 From: The Doctor <drwho(a)virtadpt.net> To: tor-talk(a)lists.torproject.org Subject: Re: [tor-talk] Exit node stats collection? Organization: Virtual Adept Networks, Unlimited User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130514 Thunderbird/17.0.6 Reply-To: tor-talk(a)lists.torproject.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 09/03/2013 06:06 PM, mirimir wrote: > How would one identify new, and suddenly very popular, hidden > services? I do not know if this link has been posted yet, but this jumped out at me this morning - it's a technique for correlating publically known Tor nodes against hidden services: http://cybermashup.com/2013/09/04/dont-run-a-tor-router-and-a-hidden-servic… Thoughts from the community? - -- The Doctor [412/724/301/703] [ZS] Developer, Project Byzantium: http://project-byzantium.org/ PGP: 0x807B17C1 / 7960 1CDC 85C9 0B63 8D9F DD89 3BD8 FF2B 807B 17C1 WWW: https://drwho.virtadpt.net/ "It is the mark of an educated mind to be able to entertain a thought without accepting it." --Aristotle -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlInansACgkQO9j/K4B7F8HwgwCfc1irnBwHpVmfV2Ge4ank1xLH KbIAoIgMqFH2t2NytXCQnJShwWyDct14 =jMxZ -----END PGP SIGNATURE----- -- tor-talk mailing list - tor-talk(a)lists.torproject.org To unsusbscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5

1 0

Re: [Cryptography] Popular curves (was: NSA and cryptanalysis)
by Eugen Leitl 04 Sep '13

04 Sep '13

----- Forwarded message from Jose Luis Gomez Pardo <gomez.pardo(a)usc.es> ----- Date: Wed, 04 Sep 2013 18:35:52 +0200 From: Jose Luis Gomez Pardo <gomez.pardo(a)usc.es> To: ianG <iang(a)iang.org> Cc: Phillip Hallam-Baker <hallam(a)gmail.com>, cryptography(a)metzdowd.com Subject: Re: [Cryptography] Popular curves (was: NSA and cryptanalysis) X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 At 08:20 04/09/2013, ianG wrote: > On 3/09/13 18:13 PM, Phillip Hallam-Baker wrote: > .... >> Do we have an ECC curve that is (1) secure and (2) has a written >> description prior to 1 Sept 1993? > > > (Not answering your direct question.) Personally, I was happy to > plan on using DJB's Curve25519. He's done the research and says it > is good. Comments? > > iang Curve25519 was designed for elliptic Diffie-Hellman taking care of both security and efficiency aspects and seems very strong in both of them. Some comments on its usage for other purposes can be found in http://stackoverflow.com/questions/2515948/use-of-curve25519 This curve was originally written for x86 32-bit platforms and a 64-bit implementation can be found in the following links: https://code.google.com/p/curve25519-donna/ https://github.com/agl/curve25519-donna In addition to this curve and to the NIST curves, another source for elliptic curves that can be (according to the developers) freely used is: http://certivox.org/display/EXT/CertiVox+Standard+Curves where cuves over 384 and 512-bit prime fields can be found which are likely secure. Of course, in all these cases you have to trust the curve developers somewhat although you can also check these curves for possible vulnerabilities. Alternatively, one can build one's own curve and for this one needs to have access to an implementation of the SEA point counting algorithm. A little while ago I was writing a cryptography book that uses Maple to implement both cryptographic schemes and cryptanalytic algorithms and, for a while, I contemplated the idea of programming SEA in Maple. However, I soon discarded it because there are already some freely available excelent implementations in compiled languages and my Maple implementation would necessarily be much slower. Thus, for some computations in the examples in my book I ended using MIRACL, a C/C++ library with excellent support for ECC which was recently adquired by CertiVox and can be found in the following links: http://www.certivox.com/miracl/ https://github.com/CertiVox/MIRACL Using the SEA algorithm one can readily find elliptic curves of prime order (or with a very small cofactor) which, additionally, can be tested to ensure that they satisfy some important conditions such as not having small embedding degree (to prevent the MOV reduction attack) or not having trace one (anomalous curves) which makes them also vulnerable. Of course, if the curves are (pseudo)randomly generated, it is very unlikely that they suffer from these vulnerabilities. Methods for verifiably random generation of such curves can be found in: http://www.secg.org/download/aid-780/sec1-v2.pdf and some recommended elliptic curves generated using these methods (including curves over 384-bit and 521-bit prime fields) are available from: http://www.secg.org/download/aid-784/sec2-v2.pdf Of course, I don't know whether these curves are completely free from IP concerns but, according to the sources where these curves are published, this seems to be the case (I am far from expert in the IP subject but, as a mathematician, the idea of someone "owning" an elliptic curve in some sense, seems to me very strange). Jose Luis. _______________________________________________ The cryptography mailing list cryptography(a)metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5

1 0

Safest exit country?
by Bernard Tyers - ei8fdb 04 Sep '13

04 Sep '13

Two parts: 1. Requirement: Minimise the possibility of surveillance at egress point. Surveillance of the wire between my country X and the egress country Z is not a concern. (NB: It is a concern, but not taken into account in this thought experiment) Question: If I was able to choose which country to route my IP traffic through and have act as my egress point to "the Internet public" which country would I choose? 2. Question: Is Iceland as safe as people think? Safe is defined as a location where surveillance and monitoring is minimal/non-existent. My answer: No. Thanks, Bernard -------------------------------------- Bernard / bluboxthief / ei8fdb IO91XM / www.ei8fdb.org

6 9

Re: [Cryptography] NSA and cryptanalysis
by John Young 04 Sep '13

04 Sep '13

Still, it is not easy knowing who is who when they play the same game using the same strategies, moves, gambits, ploys, feints, struts, deceptions. This mirroring of the opposition is a long tradition of authorities, their covert agents and provocateurs manipulating their citizenry, consumers, fans, doling out manufactured information. No doubt the game advances the interests of all the games players so long as they follow their agreed upon rules and cheat very carefully. We may admire their skill and daring and triumphs but the rules state we are not qualified to be the players, that requires ranking by authorities of the game. Assange was once not a player, studied hard, watched the masters, now he is surrounded by grand masterful players and reaps the rewards of fame, acclaim, and happily the monetary prizes, to be sure spending a lot of that on lawyers and promoters. So it goes. Meanwhile there is a need for more undoctored documents for the newbies and bystanders angling for a chance, for consumers to see what happens offstage, how vetting and redacting, parceling and censoring is done. But Assange and cohorts have become secretive about the WikiLeaks operation and apparently (who knows) hidden stashes of income, in concert with the practices of secretkeepers of all stripes. And not least WL engages in defamation to an almost hysterical extent that suggests much to hide, again mirroring authoritarian shilling. Promoting adversarialism is ancient theocracy where only priests play the game they rig. Let us all play, unmedicated by reputation-mongering tradecraft of TV, news, advertizing, limited access to documentation and overload of "if you knew what we know, trust us" pulp fiction. At 10:21 AM 9/4/2013, you wrote: >2013/9/4 John Young <<mailto:jya@pipeline.com>jya(a)pipeline.com> >The Snowden material needs an untethered, unchoked, >and unmarionetted leaker not more commercial journalism >dribbling what, unforntunately has become common in the >"era of WikiLeaks journalism," is disinfo. And implies the >prospect of complicity with authorities under rigging of >privileged journalism and coddled D-Noticers. > > >You could say playing games is what politicians do. But not playing >the games means you get no game. Assange does explicitly, publicly >and knowingly play games. He knows they work. Had all the documents >been published unedited there would be a single headline in every newspaper. > >Now there's thousands. Every week it's hammered upon. We see people >claiming "Oh, see, the NSA said something to make it okay, and I >think it actually is!" only to be stomped by the next headline >showing it was definitely not okay. This releasing scheme is a very, >very good match for the current journalistic reality. > >Given Assange seems to be pretty well on the side of civil liberty, >freedom and power, I think he's doing a rather good job.

2 1

Re: [Cryptography] NSA and cryptanalysis
by John Young 04 Sep '13

04 Sep '13

> > you have to wish that the news reporters publish the actual doc instead > > of uselessly paraphrasing it in an effort to claim interpretive credit. This is the achilles heel of the Snowden drop. PowerPoint, Photoshop and redactions coutured in editorial elaboration of documents not revealed is exactly what officials do to spin material and manipulate the public. The Snowden material needs an untethered, unchoked, and unmarionetted leaker not more commercial journalism dribbling what, unforntunately has become common in the "era of WikiLeaks journalism," is disinfo. And implies the prospect of complicity with authorities under rigging of privileged journalism and coddled D-Noticers. The Guardian has belatedly confessed to that. And WaPo and the NYT have they have and will vet Snowden material with the USG before release. Which suggests cotinuation of a lot more editorial elaboration, TV garavitasing, bowdlerized reports and articles, Dough-Boy books, Op X films, primly steriolized documentaries. In effect, a propaganda push right out of the 1950s through the 2010s configured for cyberwar coldwar. Manchurian Assange, Manning, Snowden featured a la Zizek in the Guardian yesterday. Little crypto will be revealed, except misleading urge to use it as Snowden has done, instead much fancified metadata -- not to overlook the metaphysics of hyping entertaining leakage, now a booming culture of deceit continuing the cult of spy fiction began in days of Art of War. >If there's breaks with any "B" or other respected public algos, >you can bet they keep that well compartmented. Losing some >node somewhere is no big deal. Going dark on all your nodes >as a result of wholesale crypto replacement response would >be a big deal. > >Knowledge of "A" would indeed be interesting to instructive.

2 1

[Bitcoin-development] 0.8.4 released, fixes critical denial-of-service issue
by Eugen Leitl 04 Sep '13

04 Sep '13

----- Forwarded message from Gavin Andresen <gavin(a)bitcoinfoundation.org> ----- Date: Wed, 4 Sep 2013 11:16:35 +1000 From: Gavin Andresen <gavin(a)bitcoinfoundation.org> To: Bitcoin Dev <bitcoin-development(a)lists.sourceforge.net> Subject: [Bitcoin-development] 0.8.4 released, fixes critical denial-of-service issue Bitcoin-Qt version 0.8.4 is now available from: http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.8.4/ This is a maintenance release to fix a critical bug and three security issues; we urge all users to upgrade. There were no changes from 0.8.4 release candidate 2, so if you are running 0.8.4rc2 you do not need to upgrade. Please report bugs using the issue tracker at github: https://github.com/bitcoin/bitcoin/issues How to Upgrade -------------- If you are running an older version, shut it down. Wait until it has completely shut down (which might take a few minutes for older versions), then run the installer (on Windows) or just copy over /Applications/Bitcoin-Qt (on Mac) or bitcoind/bitcoin-qt (on Linux). If you are upgrading from version 0.7.2 or earlier, the first time you run 0.8.4 your blockchain files will be re-indexed, which will take anywhere from 30 minutes to several hours, depending on the speed of your machine. 0.8.4 Release notes =================== Security issues --------------- An attacker could send a series of messages that resulted in an integer division-by-zero error in the Bloom Filter handling code, causing the Bitcoin-Qt or bitcoind process to crash. Bloom filters were introduced with version 0.8, so versions 0.8.0 through 0.8.3 are vulnerable to this critical denial-of-service attack. A constant-time algorithm is now used to check RPC password guess attempts; fixes https://github.com/bitcoin/bitcoin/issues/2838 (CVE-2013-4165) Implement a better fix for the fill-memory-with-orphan-transactions attack that was fixed in 0.8.3. See https://bitslog.wordpress.com/2013/07/18/buggy-cve-2013-4627-patch-open-new… for a description of the weaknesses of the previous fix. (CVE-2013-4627) Bugs fixed ---------- Fix multi-block reorg transaction resurrection. Fix non-standard disconnected transactions causing mempool orphans. This bug could cause nodes running with the -debug flag to crash. OSX: use 'FD_FULLSYNC' with LevelDB, which will (hopefully!) prevent the database corruption issues many people have experienced on OSX. Linux: clicking on bitcoin: links was broken if you were using a Gnome-based desktop. Fix a hang-at-shutdown bug that only affects users that compile their own version of Bitcoin against Boost versions 1.50-1.52. Other changes ------------- Checkpoint at block 250,000 to speed up initial block downloads and make the progress indicator when downloading more accurate. Thanks to everybody who contributed to the 0.8.4 releases! ---------------------------------------------------------- Pieter Wuille Warren Togami Patrick Strateman pakt Gregory Maxwell Sergio Demian Lerner grayleonard Cory Fields Matt Corallo Gavin Andresen ------------------------------------------------------------------------------ Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more! Discover the easy way to master current and previous Microsoft technologies and advance your career. Get an incredible 1,500+ hours of step-by-step tutorial videos with LearnDevNow. Subscribe today and save! http://pubads.g.doubleclick.net/gampad/clk?id=58040911&iu=/4140/ostg.clktrk _______________________________________________ Bitcoin-development mailing list Bitcoin-development(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5

1 0

[tor-talk] Tor Weekly News — September 4th, 2013
by Eugen Leitl 04 Sep '13

04 Sep '13

----- Forwarded message from Lunar <lunar(a)torproject.org> ----- Date: Wed, 4 Sep 2013 12:51:54 +0200 From: Lunar <lunar(a)torproject.org> To: tor-news(a)lists.torproject.org, tor-talk(a)lists.torproject.org Subject: [tor-talk] Tor Weekly News — September 4th, 2013 User-Agent: Mutt/1.5.21 (2010-09-15) Reply-To: tor-talk(a)lists.torproject.org ======================================================================== Tor Weekly News September 4th, 2013 ======================================================================== Welcome to the tenth issue of Tor Weekly News, the weekly newsletter that covers what is happening in the skyrocketing Tor community. Serious network overload ------------------------ <borealis> if it really is a coordinated attack from a bot twice the size of the regular tor network i'm much surprised tor is still usable at all — #tor, 2013-09-02 18:38 UTC The tremendous influx of new clients that started mid-August [1] is stretching the current Tor network and software to its limits. Several relay operators reported their relays to be saturated [2] by the amount of connections and circuits that relays currently have to handle [3]. Mike Perry wishing to “compare load characteristics since 8/19 for nodes with different types of flags” issued a call to relay operators [4]: “especially useful [are] links/graph images for connection counts, bandwidth, and CPU load since 8/19.” It was reported on IRC that on some relays, only one circuit was successfully created out of four attempts. This unfortunately implies that clients retry to build more circuits, resulting in even more load on Tor relays. The tor 0.2.4 series introduced a new circuit extension handshake dubbed “ntor” [5]. This new handshake is faster (especially on the relay side) than the original circuit extension handshake, “TAP”. Roger Dingledine came up with a patch to prioritize circuit creations using ntor over TAP [6]. Various observers reported that these overwhelming unidentified new clients were likely to be using Tor 0.2.3. Prioritizing ntor is then likely to make them less a burden for the network, and should help the network to function despite being overloaded by circuit creations. Sathya and Isis both reported the patch to work. Nick Mathewson pointed out a few issues in the current implementation [7] but overall it looks like a band-aid good enough for the time being. [1] https://metrics.torproject.org/users.html?graph=direct-users&start=2013-08-… [2] https://lists.torproject.org/pipermail/tor-relays/2013-August/002594.html [3] https://lists.torproject.org/pipermail/tor-relays/2013-August/002589.html [4] https://lists.torproject.org/pipermail/tor-relays/2013-August/002612.html [5] https://gitweb.torproject.org/torspec.git/blob_plain/HEAD:/proposals/216-nt… [6] https://bugs.torproject.org/9574#comment:10 [7] https://bugs.torproject.org/9574#comment:12 Latest findings regarding traffic correlation attacks ----------------------------------------------------- Erik de Castro Lopo pointed tor-talk readers [8] to a new well written paper named “Users Get Routed: Traffic Correlation on Tor by Realistic Adversaries.” [9] To be presented at the upcoming CCS 2013 conference [10] this November in Berlin, Aaron Johnson, Chris Wacek, Rob Jansen, Micah Sherr, and Paul Syverson describe their experiments on traffic correlation attacks. This research paper follows on a long series of earlier research papers to better understand how Tor is vulnerable to adversaries controlling portions of the Tor network or monitoring users and relays at the network level. Roger Dingledine wrote to tor-talk readers [11]: “Yes, a big enough adversary can screw Tor users. But we knew that. I think it’s great that the paper presents the dual risks of relay adversaries and link adversaries, since most of the time when people are freaking out about one of them they’re forgetting the other one. And we really should raise the guard rotation period. If you do their compromise graphs again with guards rotated every nine months, they look way different.” One tricky question with raising guard rotation period [12] is: “How do we keep clients properly balanced to match the guard capacities?” [13] It is also probably another signal for any Tails supporter that wishes to help implementing guard persistence [14]. “I have plans for writing a blog post about the paper, to explain what it means, what it doesn’t mean, what we should do about it, and what research questions remain open” wrote Roger. Let’s stay tuned! [8] https://lists.torproject.org/pipermail/tor-talk/2013-September/029755.html [9] http://www.ohmygodel.com/publications/usersrouted-ccs13.pdf [10] http://www.sigsac.org/ccs/CCS2013/ [11] https://lists.torproject.org/pipermail/tor-talk/2013-September/029756.html [12] https://bugs.torproject.org/8240 [13] https://bugs.torproject.org/9321 [14] https://labs.riseup.net/code/issues/5462 A peek inside the Pirate Browser -------------------------------- Torrent-sharing website The Pirate Bay started shipping a custom browser — the Pirate Browser — on August 10th. They advertised using Tor to circumvent censorship but unfortunately did not provide any source code for their project. Matt Pagan examined the contents of the package [15] in order to get a better idea of what it was. He compared the contents of the Pirate Browser 0.6b archive using cryptographic checksums to the contents of the Tor Browser Bundle 2.3.25-12 (en-US version). According to Matt’s findings the Pirate Browser includes unmodified versions of tor 0.2.3.25 and Vidalia 0.2.20. The tor configuration contains slight deviation from the one shipped with the Tor Browser Bundle. One section labeled “Configured for speed” unfortunately shows wrong understanding of the Tor network. Roger Dingledine commented in a subsequent email [16]: “Just for the record, the three lines here don’t help speed much (or maybe at all).” The remaining configuration change that “probably has the biggest impact on performance“, according to Roger, excludes exit nodes from Denmark, Ireland, United Kindgom, the Netherlands, Belgium, Italy, China, Iran, Finland, and Norway. “Whether it improves or reduces performance [Roger] cannot say, though. Depends on a lot of complex variables around Internet topologies.” The browser itself is based of Firefox 23.0, with FoxyProxy configured to use Tor only for a few specific addresses [17], and a few extra bookmarks. Later, Matt also highlighted [18] that some important extensions of the Tor Browser, namely HTTPS Everywhere, NoScript, and Torbutton were also missing from the Pirate Browser. In any cases, the Pirate Browser is unlikely to explain the sudden influx of new Tor clients. grarpamp forwarded an email exchanged with the Pirate Browser admin contact [19] which shows that numbers (550 000 known direct downloads) and dates (“most downloads during the first week”) do not match. [15] https://lists.torproject.org/pipermail/tor-talk/2013-August/029703.html [16] https://lists.torproject.org/pipermail/tor-talk/2013-August/029729.html [17] http://piratebrowser.com/piratebrowser_patterns.json [18] https://lists.torproject.org/pipermail/tor-talk/2013-August/029707.html [19] https://lists.torproject.org/pipermail/tor-talk/2013-August/029736.html Monthly status reports for August 2013 -------------------------------------- The wave of regular monthly reports from Tor project members for the month of August has begun. Sherief Alaa released his report first [20], followed by reports from George Kadianakis [21], Lunar [22], Arturo Filastò [23], Colin C. [24], Arlo Breault [25], Philipp Winter [26], Roger Dingledine [27], Karsten Loesing [28], and Isis Lovecruft [29]. The latter also caught up with June [30], and July [31]. [20] https://lists.torproject.org/pipermail/tor-reports/2013-September/000314.ht… [21] https://lists.torproject.org/pipermail/tor-reports/2013-September/000315.ht… [22] https://lists.torproject.org/pipermail/tor-reports/2013-September/000316.ht… [23] https://lists.torproject.org/pipermail/tor-reports/2013-September/000317.ht… [24] https://lists.torproject.org/pipermail/tor-reports/2013-September/000318.ht… [25] https://lists.torproject.org/pipermail/tor-reports/2013-September/000319.ht… [26] https://lists.torproject.org/pipermail/tor-reports/2013-September/000320.ht… [27] https://lists.torproject.org/pipermail/tor-reports/2013-September/000321.ht… [28] https://lists.torproject.org/pipermail/tor-reports/2013-September/000322.ht… [29] https://lists.torproject.org/pipermail/tor-reports/2013-September/000323.ht… [30] https://lists.torproject.org/pipermail/tor-reports/2013-September/000324.ht… [31] https://lists.torproject.org/pipermail/tor-reports/2013-September/000325.ht… Help Desk Roundup ----------------- This week Tor help desk saw an increase in the number of users wanting to download or install Orbot. Orbot can be downloaded from the Google Play store, the Amazon App store, f-droid.org, and guardianproject.info. Guides on using Orbot can be found on the Guardian Project’s Orbot page [32], or on the Tor Project’s Android page [33]. It looks like Orbot is currently inaccessible from the Google Play store in Iran. Please join the discussion on tor-talk [34] if you have input about the latter. [32] https://guardianproject.info/apps/orbot/ [33] https://www.torproject.org/docs/android.html [34] https://lists.torproject.org/pipermail/tor-talk/2013-August/029684.html All versions of the Tor Browser Bundle which include tor 0.2.4.x have been reported to work in Iran. This includes the latest Pluggable Transport Bundle, the 3.0 alpha series, and the 2.4 beta series. Follow our Farsi blog [35] for more Iran related news. [35] https://fa-blog.torproject.org/ Miscellaneous news ------------------ The next Tails contributors meeting [36] will happen on IRC on September 4th at 8pm UTC (10pm CEST). “Every one interested in contributing to Tails is welcome” to join #tails-dev on the OFTC network. [36] https://mailman.boum.org/pipermail/tails-dev/2013-August/003523.html Yawning Angel has been “designing a UDP based protocol to serve as the bulk data transport for something along the lines of ‘obfs3, but over UDP’.” They are soliciting feedback on their initial draft of the Lightweight Obfuscated Datagram Protocol (LODP) [37]. [37] https://lists.torproject.org/pipermail/tor-dev/2013-August/005334.html Kévin Dunglas announced [38] their work on a PHP library for the Tor Control Port [39], released under the MIT license. [38] https://lists.torproject.org/pipermail/tor-dev/2013-August/005340.html [39] https://github.com/dunglas/php-torcontrol/ Kathy Brade and Mark Smith have released a first patch [40] for Mozilla’s update mechanism which “successfully updated TBB on Linux, Windows, and Mac OS ‘in the lab’ using both incremental and ‘full replace’ updates.” This is meant for the 3.x series of the Tor Browser Bundle and is still a work a progress, but this is a significant milestone toward streamlined updates for TBB users. [40] https://bugs.torproject.org/4234#comment:19 Erinn Clark announced [41] that the software powering trac.torproject.org has been upgraded to version 0.12.3. Among several other improvements, this new version allowed Erinn to experiment with the often requested Git integration [42]. [41] https://lists.torproject.org/pipermail/tor-dev/2013-August/005328.html [42] https://lists.torproject.org/pipermail/tor-dev/2013-September/005346.html David Goulet has released the second release candidate for the 2.0 rewrite of Torsocks [43]: “Please continue to test, review and contribute it!” [43] https://lists.torproject.org/pipermail/tor-dev/2013-September/005359.html Much to her surprise, Erinn Clark found a “fraudulent PGP key with [her] email address” on the keyservers [44]. “Do not under any circumstances trust anything that may have ever been signed or encrypted with this key” of short id 0xCEE1590D. She reminded that the Tor Project official signatures are listed on the project’s website [45]. [44] https://lists.torproject.org/pipermail/tor-dev/2013-September/005348.html [45] https://www.torproject.org/docs/signing-keys.html Philipp Winter published the final paper version [46] of the ScrambleSuit pluggable transport [47], dubbed “A Polymorphic Network Protocol to Circumvent Censorship”. [46] http://www.cs.kau.se/philwint/pdf/wpes2013.pdf [47] http://www.cs.kau.se/philwint/scramblesuit/ Upcoming events --------------- Sep 4 8pm | Tor Q&A with Roger Dingledine | University of the Sciences, Philadelphia, PA, USA | http://www.phillylinux.org/meetings.html | Sep 29-01 | Tor at OpenITP Circumvention Tech Summit IV | Berlin, Germany | https://www.openitp.org/openitp/circumvention-tech-summit.html | Oct 09-10 | Andrew speaking at Secure Poland 2013 | Warszawa, Poland | http://www.secure.edu.pl/ This issue of Tor Weekly News has been assembled by Lunar, dope457, mttp, malaparte, Nima, bastik, and Roger Dingledine. Want to continue reading TWN? Please help us create this newsletter. We still need more volunteers to watch the Tor community and report important news. Please see the project page [48], write down your name and subscribe to the team mailing list [49] if you want to get involved! [48] https://trac.torproject.org/projects/tor/wiki/TorWeeklyNews [49] https://lists.torproject.org/cgi-bin/mailman/listinfo/news-team -- tor-talk mailing list - tor-talk(a)lists.torproject.org To unsusbscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5

1 0

Re: [Cryptography] NSA and cryptanalysis
by Eugen Leitl 04 Sep '13

04 Sep '13

----- Forwarded message from Jerry Leichter <leichter(a)lrw.com> ----- Date: Mon, 2 Sep 2013 00:06:21 -0400 From: Jerry Leichter <leichter(a)lrw.com> To: "Perry E. Metzger" <perry(a)piermont.com> Cc: "cryptography(a)metzdowd.com List" <cryptography(a)metzdowd.com> Subject: Re: [Cryptography] NSA and cryptanalysis X-Mailer: Apple Mail (2.1283) On Sep 1, 2013, at 6:06 PM, Perry E. Metzger wrote: > We know what they spec for use by the rest of the US government in > Suite B. > > http://www.nsa.gov/ia/programs/suiteb_cryptography/ > > AES with 128-bit keys provides adequate protection for classified > information up to the SECRET level. Similarly, ECDH and ECDSA using > the 256-bit prime modulus elliptic curve as specified in FIPS PUB > 186-3 and SHA-256 provide adequate protection for classified > information up to the SECRET level. Until the conclusion of the > transition period defined in CNSSP-15, DH, DSA and RSA can be used > with a 2048-bit modulus to protect classified information up to the > SECRET level. > > AES with 256-bit keys, Elliptic Curve Public Key Cryptography using > the 384-bit prime modulus elliptic curve as specified in FIPS PUB > 186-3 and SHA-384 are required to protect classified information at > the TOP SECRET level. Since some products approved to protect > classified information up to the TOP SECRET level will only contain > algorithms with these parameters, algorithm interoperability between > various products can only be guaranteed by having these parameters as > options. > > We clearly cannot be absolutely sure of what they actually use, but > we know what they procure commercially. If you feel this is all a big > disinformation campaign, please feel free to give evidence for that. I > certainly won't exclude the possibility, but I find it unlikely. I'll make just a couple of comments: - Given the huge amount of material classified these days, SECRET doesn't seem to be a very high level any more, whatever its official definition. TOP SECRET still means a great deal though. But the really important stuff is compartmented (SCI), and Suite B is not approved for it - it has to be protected by unpublished Suite A algorithms. - To let's look at what they want for TOP SECRET. First off, RSA - accepted for a transition period for SECRET, and then only with 2048 bit moduli, which until the last year or so were almost unknown in commercial settings - is completely out for TOP SECRET. So clearly they're faith in RSA is gone. (Same for DH and DSA.) It looks as if they are betting that factoring and discrete logs over the integers aren't as hard as people had thought. The whole business of AES-128 vs. AES-256 has been interesting from day one. Too many recommendations for using it are just based on some silly idea that bigger numbers are better - 128 bits is already way beyond brute force attacks. The two use the same transforms and the same key schedule. The only clear advantage AES-256 has is 4 extra rounds - any attack against the basic algorithm would almost certainly apply to both. On the other hand, many possible cracks might require significantly heavier computation for AES-256, even if the same fundamental attack works. One wonders.... NSA also wants SHA-384 - which is interesting given recent concerns about attacks on SHA-1 (which so far don't seem to extend to SHA-384). I don't want to get into deep conspiracy and disinformation campaign theories. My read of the situation is that at the time NSA gave its approval to this particular combination of ciphers, it believed they were secure. They seem to be having some doubts about RSA, DSA, and DH, though that could be, or could be justified as, ECC being as strong with much smaller, more practical, key lengths. Now, imagine that NSA really did find a way in to AES. If they were to suddenly withdraw approval for its use by the government, they would be revealing their abilities. A classic conundrum: How do you make use of the fruits of your cryptanalytic efforts without revealing that you've made progress? England accepted bombing raids on major cities to keep their crack of Enigma secret. So the continuation of such support tells us little. What will be interesting to see is how long the support continues. With work under way to replace SHA, a new version of the NSA recommendations will eventually have to be produced. Will it, for example, begin a phase-out of AES-128 for SECRET communications in favor of requiring AES-256 there as well? (Since there's no call so far to develop a cipher to replace AES, it would be difficult for NSA to recommend something else.) It's indeed "a wilderness of mirrors", and we can only guess. But I'm very wary of using NSA's approval of a cipher as strong evidence, as the overall situation is complex and has so many tradeoffs. -- Jerry _______________________________________________ The cryptography mailing list cryptography(a)metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5

3 2

Re: Email traffic analysis (Was: Who bought off Zimmermann?)
by Bill Stewart 04 Sep '13

04 Sep '13

At 08:43 PM 8/30/2013, grarpamp wrote: > > On 8/30/13, Jon Callas <jon(a)callas.org> wrote: > > What we're learning from Snowden is that they're doing traffic analysis -- > > analyzing movements, social graphs, and so on and so forth. The irony here > > is that this tells us that the crypto works. > >Are we sure? This seems to tell us they are doing traffic analysis >and so forth. >It doesn't seem to say much about cryptanalytic capabilities. For all we know >they could have all the crypto in the bag but need analysis to identify >talkers due to people being exceedingly careful about the message content. > >"Blue hen rides over the book on the left side when the sun is low. >Do you copy?" If they know that Alice and Bob have been sending mail to each other, that's often more valuable than the traffic itself. Certainly for the model that says they're tracking two or three degrees of separation from Alice the Foreigner, with a court letting them demand that ISPs hand over any plaintext they have, though you can avoid some of that by using remailers. >>> Received:, Message-ID:, etc. Those are tricky. They're not really part of SMTP, they're part of the email message. A "pen register" style of wiretapping the envelope gets you the SMTP headers TO and FROM and the IP addresses and email options, but at least if you're using SMTP encryption you won't get the message headers. On the other hand, if you're just using PGP or SMIME on the message body, you do get them, so that's not going to help alice(a)gmail.com much.

1 0