- cypherpunks - lists.cpunks.org

NSA's New Codebreakers
by John Young 16 Oct '13

16 Oct '13

http://www.foreignpolicy.com/articles/2013/10/15/the_nsa_s_new_codebreakers… Whew, allegedly, no dual-use, dual-contract cryptographers have been revealed by Snowden. Except cryptographers are trained experts in dual-use disinforming about comsec revelations. Seems a fair number of anonymizees duped the author of the article. No famous crypto names, please, this is a polite forum.

1 0

[tor-talk] Tor Weekly News — October 16th, 2013
by Eugen Leitl 16 Oct '13

16 Oct '13

----- Forwarded message from Lunar <lunar(a)torproject.org> ----- Date: Wed, 16 Oct 2013 14:32:48 +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 — October 16th, 2013 Message-ID: <20131016123248.GB19497@loar> User-Agent: Mutt/1.5.21 (2010-09-15) Reply-To: tor-talk(a)lists.torproject.org ======================================================================== Tor Weekly News October 16th, 2013 ======================================================================== Welcome to the sixteenth issue of Tor Weekly News, the weekly newsletter that covers what’s happening in the venerable Tor community. Making hidden services more scalable and harder to locate --------------------------------------------------------- Christopher Baines started a discussion [1] on tor-dev on the scaling issues affecting the current design of Tor hidden services. Nick Mathewson later described Christopher’s initial proposal as “single hidden service descriptor, multiple service instances per intro point” along with three other alternatives. Nick and Christopher also teamed up to produce a set of seven goals that a new hidden service design should aim for regarding scalability. There’s probably more to discuss regarding which goals are the most desirable, and which designs are likely to address them, without — as always — harming anonymity. George Kadianakis also called for help [2] concerning “the guard enumeration attack that was described by the ‘Trawling for Tor Hidden Services: Detection, Measurement, Deanonymization’ paper (in section VII)” [3]. The most popular solution so far seems to be enabling a client or hidden service to reuse some parts of a circuit that cannot be completed successfully in order to connect to new nodes. This should “considerably slow the attack” [4], but “might result in unexpected attacks” as George puts it. These problems could benefit from everyone’s attention. Free to read the threads in full and offer your insights! [1] https://lists.torproject.org/pipermail/tor-dev/2013-October/005556.html [2] https://lists.torproject.org/pipermail/tor-dev/2013-October/005621.html [3] http://www.ieee-security.org/TC/SP2013/papers/4977a080.pdf [4] https://bugs.torproject.org/9001 Detecting malicious exit nodes ------------------------------ Philipp Winter asked [5] for feedback on the technical architecture of “a Python-based exit relay scanner which should detect malicious and misbehaving exits.” Aaron took the opportunity to mention his plans [6] to leverage the work done as part of OONI [7] to detect network interference. Aaron’s intention is to “provide Tor network tests as part of ooni-probe’s standard set of tests, so that many individuals will measure the Tor network and automatically publish their results, and so that current and future network interference tests can be easily adapted to running on the Tor network.” Detecting misbehaving exits so they can be flagged “BadExit” [8] by the operators of the directory authorities is important to make every Tor user safer. Getting more users to run tests against our many exit nodes would benefit everyone — it makes it more likely that bad behavior will be caught as soon as possible. [5] https://lists.torproject.org/pipermail/tor-dev/2013-October/005593.html [6] https://lists.torproject.org/pipermail/tor-dev/2013-October/005596.html [7] https://ooni.torproject.org/ [8] https://trac.torproject.org/projects/tor/wiki/doc/badRelays Hiding location at the hardware level ------------------------------------- One of Tor’s goals is to hide the location of its users, and it does a reasonably good job of this for Internet connections. But when your threat model includes an adversary that can monitor which equipment is connected to a local network, or monitor Wi-Fi network probes received by many access points, extra precautions must be taken. Ethernet and Wi-Fi cards ship with a factory-determined hardware address (also called a MAC address) that can uniquely identify a computer across networks. Thankfully, most devices allow their hardware address to be changed by an operating system. As the Tails live operating system aims to protect the privacy and anonymity of its users, it has long been suggested [9] that it should automatically randomize MAC addresses. Some important progress has been made, and this week anonym requested comments [10] on a detailed analysis of why, when and how Tails should randomize MAC addresses. In this analysis, anonym describes a Tails user wanting to hide their geographical movement and not be identified as using Tails, but who also wants to “avoid alarming the local administrators (imagine a situation where security guards are sent to investigate an ‘alien computer’ at your workplace, or similar)” and “avoid network connection problems due to MAC address white-listing, hardware or driver issues, or similar”. The analysis then tries to understand when MAC address should be randomized depending on several combinations of locations and devices. The outcome is that “this feature is enabled by default, with the possibility to opt-out.” anonym then delves into user interface and implementation considerations. If you are interested in the analysis, or curious about how you could help with the proposed implementation, be sure to have a look! [9] https://labs.riseup.net/code/issues/5421 [10] https://mailman.boum.org/pipermail/tails-dev/2013-October/003835.html Tor Help Desk Roundup --------------------- The Tor project wishes to expand its support channels to text-based instant messaging as part of the Boisterous Otter [11] project. Lunar and Colin C. came up with a possible implementation [12] based on the XMPP protocol, Prosody [13] for the server side, and Prodromus [14] as the basis for the web based interface. This week, multiple people asked if Tor worked well on the Raspberry Pi. Although the Tor Project does not have any documentation directed specifically at the Raspberry Pi (yet!), the issue was raised on Tor’s StackExchange page [15]. Tor relay operators are encouraged to share their experiences or ask for help on the tor-relays public mailing list [16]. [11] https://trac.torproject.org/projects/tor/wiki/org/sponsors/Otter/Boisterous [12] https://trac.torproject.org/projects/tor/wiki/org/sponsors/Otter/Boisterous… [13] https://prosody.im/ [14] http://forge.webpresso.net/projects/prodromus [15] http://tor.stackexchange.com/questions/242/how-to-run-tor-on-raspbian-on-th… [16] https://lists.torproject.org/pipermail/tor-relays/ Miscellaneous news ------------------ Ten years ago, on October 8th, 2003, Roger Dingledine announced [17] the first release of tor as free software on the or-dev mailing list. [17] https://lists.torproject.org/pipermail/tor-dev/2003-October/002185.html Damian Johnson announced [18] the release of Stem 1.1.0 [19]. The new version of this “Python library for interacting with Tor” adds remote descriptor fetching, connection resolution and a myriad of small improvements and fixes. [18] https://blog.torproject.org/blog/stem-release-11 [19] https://stem.torproject.org/change_log.html#version-1-1 Arlo Breault sent out a detailed plan on how Mozilla Instantbird could be turned into the Tor Messenger [20]. Feedback would be welcome, especially with regard to sandboxing, auditing, and internationalization for right-to-left languages. [20] https://lists.torproject.org/pipermail/tor-dev/2013-October/005616.html The Spanish and German version of the Tails website are outdated and may soon be disabled [21]. Now is a good time to help [22] if you want to keep those translations running! [21] https://mailman.boum.org/pipermail/tails-dev/2013-October/003879.html [22] https://tails.boum.org/contribute/how/translate/ adrelanos announced [23] the release of Whonix 7, an operating system “based on Tor […], Debian GNU/Linux and the principle of security by isolation.” The new version includes tor 0.2.4, Tor Browser as the system default browser and a connection wizard, among other changes. [23] https://lists.torproject.org/pipermail/tor-talk/2013-October/030593.html Lunar sent out a report about the Dutch OHM2013 hacker camp [24] that took place in August. [24] https://lists.torproject.org/pipermail/tor-reports/2013-October/000363.html Philipp Winter, Justin Bull and rndm made several improvements to Atlas [25], the web application for learning more about currently-running Tor relays. The HSDir flag is now properly displayed [26], full country names and flags are shown instead of two-letter codes [27] and it’s now easier to find out how long a relay has been down [28]. [25] https://atlas.torproject.org/ [26] https://bugs.torproject.org/9911 [27] https://bugs.torproject.org/9914 [28] https://bugs.torproject.org/9814 ra, one of Tor’s former GSoC students, proposed a patch [29] to add a command to the Tor control protocol asking tor to pick a completely new set of guards. [29] https://bugs.torproject.org/9934 starlight shared some simple shell snippets [30] that connect to the Tor control port in order to limit the bandwidth used by a relay while running backups. [30] https://lists.torproject.org/pipermail/tor-talk/2013-October/030607.html Upcoming events --------------- Nov 04 | Workshop on Privacy in the Electronic Society | Berlin, Germany | http://wpes2013.di.unimi.it/ | Nov 04-05 | 20th ACM Conference on Computer and Communications Security | Berlin, Germany | http://www.sigsac.org/ccs/CCS2013/ This issue of Tor Weekly News has been assembled by Lunar, Matt Pagan, harmony, dope457, Damian Johnson and Philipp Winter. 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 [31], write down your name and subscribe to the team mailing list [32] if you want to get involved! [31] https://trac.torproject.org/projects/tor/wiki/TorWeeklyNews [32] https://lists.torproject.org/cgi-bin/mailman/listinfo/news-team -- tor-talk mailing list - tor-talk(a)lists.torproject.org To unsubscribe 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

Why Android SSL was downgraded from AES256-SHA to RC4-MD5 in late 2010
by Rich Jones 16 Oct '13

16 Oct '13

Nasty: http://op-co.de/blog/posts/android_ssl_downgrade/ Looks like ignorance rather than malice, but that's a pretty fucking bone-headed maneuver. Normally the Android guys are quite sharp, so a mistake like this actually strikes me as a little bit fishy. Here's the guy responsible for the commit: http://carlstrom.com/ http://www.linkedin.com/in/carlstrom Worth a follow-up? R

2 1

Re: [liberationtech] RiseUp
by Eugen Leitl 16 Oct '13

16 Oct '13

----- Forwarded message from elijah <elijah(a)riseup.net> ----- Date: Tue, 15 Oct 2013 15:47:15 -0700 From: elijah <elijah(a)riseup.net> To: liberationtech <liberationtech(a)lists.stanford.edu> Subject: Re: [liberationtech] RiseUp Message-ID: <525DC5F3.8010604(a)riseup.net> User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 Reply-To: liberationtech <liberationtech(a)lists.stanford.edu> On 10/15/2013 03:07 PM, Yosem Companys wrote: > If you have any thoughts about Riseup, whether > security/privacy-related or otherwise, I'd love to hear them. I think I am the only person from the Riseup collective who is subscribed to liberationtech, so I will reply, although what follows is not an official position or response from the collective. We started when it was impossible to get even simple IMAP service that was affordable. Very early on, it became apparent that one of the primary issue facing our constituency (social justice activists) was the rapid rise in abusive surveillance by states and corporations. Riseup does the best it can with antiquated 20th century technology. Without getting into any details, we do the best that can be done, particularly when both sender and recipient are using email from one of service providers we have special encrypted transport arrangements with. Admittedly, the best we can do is not that great. And, of course, our webmail offering is laughably horrible. Riseup is not really a "US email provider". The great majority of our users live outside the United States, and email is just one of many services we provide. There has been much discussion on the internets about the fact that Riseup is located in the US, and what possible country would provide the best "jurisdictional arbitrage". Before the Lavabit case, the US actually looked pretty good: servers in the US are not required to retain any customer data or logs whatsoever. The prospect of some shady legal justification for requiring a provider to supply the government with their private TLS keys seems to upend everything I have read or been told about US jurisprudence. Unfortunately, no consensus has emerged regarding any place better than the US for servers, despite notable bombast the the contrary. As a co-founder of Riseup, my personal goal at the moment is to destroy Riseup as we know it, and replace it with something that is based on 21st century technology [1]. My hope is that this transition can happen smoothly, without undo hardship on the users. As evidence by the recent traffic on this list, many people are loudly proclaiming that email can never be secure and it must be abandoned. I have already written why I feel that this is both incredibly irresponsible and technically false. There is an important distinction between mass surveillance and being individually targeted by the NSA. The former is an existential threat to democracy and the latter is extremely difficult to protect against. It is, however, entirely possible to layer a very high degree of confidentially, integrity, authentication, and un-mappability onto email if we allow for opportunistic upgrades to enhanced protocols. For example, we should be able to achieve email with asynchronous forward secrecy that is also protected against meta-data analysis (even from a compromised provider), but it is going to take work (and money) to get there. Yes, in the long run, we should all just run pond [2], but in the long run we are all dead. -elijah [1] https://leap.se/email [2] https://pond.imperialviolet.org/ -- Liberationtech is public & archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at companys(a)stanford.edu. ----- 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

2 1

Re: <nettime> Pascal Zachary: Rules for the Digital Panopticon (IEEE)
by Eugen Leitl 16 Oct '13

16 Oct '13

----- Forwarded message from John Hopkins <jhopkins(a)neoscenes.net> ----- Date: Tue, 15 Oct 2013 21:24:48 -0700 From: John Hopkins <jhopkins(a)neoscenes.net> To: nettime-l(a)mail.kein.org Subject: Re: <nettime> Pascal Zachary: Rules for the Digital Panopticon (IEEE) Message-ID: <525E1510.50106(a)neoscenes.net> Organization: neoscenes User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 Reply-To: jhopkins(a)neoscenes.net, a moderated mailing list for net criticism <nettime-l(a)mail.kein.org> HI Florian -- > In 2013, we're watching this history repeat itself as a farce. Many > people (myself included) are flabbergasted by the lack of mass-scale > protest against the government programs disclosed by Snowden. It > seems as if two Speaking from the Belly of the Beast (semi-rural Arizona, next to Idaho and Alaska in terms of right-wing folks), the media consumption and actual media content here is literally stunning -- the volume on shouting heads (never-mind talking heads!!!) has the media consumer floating like a half-dead fish on the surface after dynamite in the water... It's coming from all directions, and just wait for maybe next week, when Social Security checks stop. There will be (armed) people on the streets... I see evidences of Empire in serious decline and I believe this strange passive-aggressivity will only increase as a feature of the whole damn thing. Where I am the dominant sentiment is not a far stretch from rural Afghanistan where many folks are heavily armed in their homes. Much more than an AK-47 for every man... FYI, my friend, the writer George Saunders had a great book out a couple years ago with the lead short story "The Braindead Megaphone" which explores the chilling scenario from a harsh satirical pov... but this shit is serious... You are only flabberghasted 'cause, maybe, you maybe believed a tiny bit of the 'US exceptionalism' mythology... The reality of Empire is ... the reality of Empire. > Teaching a mixed group of third year Bachelor-level students of > informatics, media technology and media design, I learned that > even most of them did not know or understand systems like PRISM, > commercial mining of personal data and big data operations. I stepped away from teaching (several Digital Art courses and a course titled "Meaning of Information Technology"* at the University of Colorado Boulder this year because of a deep inability on the part of the students that I had to engage in any critical discourse about technology, period. Of course, as a learning facilitator, I'm supposed to be able to make this happen, but there was another dynamic apparent -- that even the possibility (the concept!) critical engagement was not available to the students -- perhaps as a result of the "No Child Left Behind" educational policies of the Bush Regime which emphasized teaching to tests. For the first time in my 25+ years teaching path, I gave up. The brightest students were left to literally go crazy trying to extract something meaningful from their (corporate) educational experience. * It was a survey seminar for a "Technology Arts & Media" minor -- syllabus @ http://neoscenes.net/teach/cu/2013_1/atls2000_mit/syllabus.html -- I had students from practically every major on campus both humanities and sci/eng people. Facilitating a collaborative and open knowledge-building process was definitely a question of moving against a strong current... Anyway... JH -- ++++++++++++++++++++++++++++++++++++++++++++++++++ Dr. John Hopkins, BSc, MFA, PhD ensconced, unarmed and dangerous, in an ultra-conservative stronghold http://neoscenes.net/ http://tech-no-mad.net/blog/ ++++++++++++++++++++++++++++++++++++++++++++++++++ # distributed via <nettime>: no commercial use without permission # <nettime> is a moderated mailing list for net criticism, # collaborative text filtering and cultural politics of the nets # more info: http://mx.kein.org/mailman/listinfo/nettime-l # archive: http://www.nettime.org contact: nettime(a)kein.org ----- 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-dev] Attentive Otter IM: tomorrow Wednesday 2013-10-16 at 1400h Pacific
by Eugen Leitl 16 Oct '13

16 Oct '13

----- Forwarded message from Tom Lowenthal <me(a)tomlowenthal.com> ----- Date: Tue, 15 Oct 2013 22:01:29 -0700 From: Tom Lowenthal <me(a)tomlowenthal.com> Cc: Tor Assistants <tor-assistants(a)lists.torproject.org>, tor-dev(a)lists.torproject.org Subject: [tor-dev] Attentive Otter IM: tomorrow Wednesday 2013-10-16 at 1400h Pacific Message-ID: <CAFnoQs-d79BOh_Vv5D_GHbX8iaBb1v=yKK4DBvPTBFBeS1EKeg(a)mail.gmail.com> Reply-To: tor-dev(a)lists.torproject.org Sorry about this late notice too. I thought I'd sent these times out already, but apparently I was rather mistaken. We'll be in #tor-dev tomorrow Wednesday 2013-10-16 at 1430 Pacific to talk about the Tor IM project. We may take up to 90 minutes, and plan to meet again next week, probably at the same time unless there are conflicts. Arlo came up with [a cunning plan][1] m'lord. You should totes read it and come tomorrow with questions and suggestions about how best to implement Instantbird as the Tor IM app. See y'all tomorrow. Play nice, now. -Tom [1]: https://gist.github.com/arlolra/6969273 _______________________________________________ tor-dev mailing list tor-dev(a)lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev ----- 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-dev] Cute Otter hidden services & publishing: tomorrow Wednesday 2013-10-16 at 1130 Pacific
by Eugen Leitl 16 Oct '13

16 Oct '13

----- Forwarded message from Tom Lowenthal <me(a)tomlowenthal.com> ----- Date: Tue, 15 Oct 2013 21:40:33 -0700 From: Tom Lowenthal <me(a)tomlowenthal.com> To: Nick Mathewson <nickm(a)alum.mit.edu>, Michele Orru <maker(a)tumbolandia.net>, SiNA Rabbani <sina(a)redteam.io> Cc: Tor Assistants <tor-assistants(a)lists.torproject.org>, tor-dev(a)lists.torproject.org Subject: [tor-dev] Cute Otter hidden services & publishing: tomorrow Wednesday 2013-10-16 at 1130 Pacific Message-ID: <CAFnoQs8LyQ=R4Ms6cRH+X8G8sr5MiaYHTAVVEJ6CgStMh1xNLA(a)mail.gmail.com> Reply-To: tor-dev(a)lists.torproject.org Sorry about the late notice, folks. I thought I'd sent these times out already, but apparently I was rather mistaken. We'll be in #tor-dev tomorrow Wednesday 2013-10-16 at 1130 Pacific to talk about hidden services, scaling thereof, and safe publishing therewith. We may take up to 90 minutes, and plan to meet again next week, probably at the same time unless there are conflicts. It'd be super neat if you could familiarize yourself with [Sina's proposal][1] before the meeting. Come with constructive comments and suggestions. See y'all tomorrow. -Tom [1]: https://lists.torproject.org/pipermail/tor-dev/2013-October/005558.html _______________________________________________ tor-dev mailing list tor-dev(a)lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev ----- 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

The NSA back door to NIST
by Eugen Leitl 16 Oct '13

16 Oct '13

http://jiggerwit.wordpress.com/2013/09/25/the-nsa-back-door-to-nist/ Thomas C. Hales (University of Pittsburgh) (This article will be published in the Notices of the American Mathematical Society.) Use once. Die once. — activist saying about insecure communication This article gives a brief mathematical description of the NIST standard for cryptographically secure pseudo-random number generation by elliptic curves, the back door to the algorithm discovered by Ferguson and Shumow, and finally the design of the back door based on the Diffie-Hellman key exchange algorithm. NIST (the National Institute for Standards and Technology) of the U.S. Department of Commerce derives its mandate from the U.S. Constitution, through the congressional power to “fix the standard of weights and measures.” In brief, NIST establishes the basic standards of science and commerce. Whatever NIST says about cryptography becomes implemented in cryptographic applications throughout U.S. government agencies. Its influence leads to the widespread use of its standards in industry and the broad adoption of its standards internationally. Through the Snowden disclosures, the NIST standard for pseudo-random number generation has fallen into disrepute. Here I describe the back door to the NIST standard for pseudo-random number generation in elementary and mathematically precise terms. The NIST standard offers three methods for pseudo-random number generation [NIST]. My remarks are limited to the third of the three methods, which is based on elliptic curves. Random number generators can either be truly random (obtaining their values from randomness in the physical world such as a quantum mechanical process) or pseudo-random (obtaining their values from a deterministic algorithm, yet displaying a semblance of randomness). The significance of random number generation within the theory of algorithms can be gauged by Knuth’s multivolume book, The Art of Computer Programming. It devotes a massive 193 pages (half of volume two) to the subject! A subclass of pseudo-random number generators are cryptographically secure, intended for use in cryptographic applications such as key generation, one-way hash functions, signature schemes, private key cryptosystems, and zero knowledge interactive proofs [Luby]. Elliptic curves as pseudo-random number generators The NIST standard gives a list of explicit mathematical data (E,p,n,f,P,Q) to be used for pseudo-random number generation [NIST]. Here E is an elliptic curve defined over a finite field \mathbb{F}_p of prime order p. The group E(\mathbb{F}_p) has order n, which is prime for all of the curves that occur in the NIST standard. The elements of the group E(\mathbb{F}_p) consist of the set of points on an affine curve, together with a point at infinity which serves as the identity element of the group. The affine curve is defined by an equation y^2 = f(x) for some explicit cubic polynomial f in \mathbb{F}_p[x]. Finally, P and Q are given points on the affine curve. NIST gives a few sets of data and in each case the prime number p is large. (The smallest is greater than 10^{77}.) No explanation is given of the particular choices (E,p,n,f,P,Q). We are told to use these data and not to question why. The standard stipulates that “one of the following NIST approved curves with associated points shall be used in applications requiring certification under FIPS-140 [U.S. government computer security accreditation].” When A is any point other than the identity in E(\mathbb{F}_p), we may evaluate the coordinate function x at A, to obtain x(A)\in \mathbb{F}_p. By further lifting \mathbb{F}_p to a set of representatives in \mathbb{Z}, we obtain a function by composition x1 : E(\mathbb{F}_p)\setminus\{0\}~ \to~ \mathbb{F}_p~\to~ \mathbb{Z}. Write (n,A)\mapsto n * A for the \mathbb{Z}-module action of \mathbb{Z} on E. (We write powers of the group element A using multiplicative rather than exponential notation.) The pseudo-random bit generator is initialized with a random integer seed s, obtained by some different process such as a separate random number generator. What is important for us is that the number s represents the hidden internal state of the algorithm. The hidden state must be kept secret for the pseudo-randomness to be effective. (Once the state is disclosed, a pseudo-random sequence becomes predictable and useless for many cryptographic purposes.) The essence of the pseudo-random bit generator can be written in the Objective Caml language as follows. In the syntax of this language, each phrase (let x = a in …) defines the value of x to be a. The last line of the block of code gives the output of the function. let pseudo_random s = let r = x1 (s * P) in let s' = x1 (r * P) in let t = x1 (r * Q) in let b = extract_bits t in (s',b); That is, we successively apply the integer s or r to the point P or the point Q and take the x1 coordinate of the resulting point, then extract some bits from the number t. The integer s’ becomes the new secret internal state to be fed into the next iteration of the function. The output b is passed to the consumer of pseudo-random bits. This output may become publicly known. The function extract_bits operates by converting t to a list of bits, discarding the 16 most significant bits (for reasons that do not matter to this discussion), and giving the remaining bits as output. According to NIST standards, by iterating this function, updating the internal state at each iteration, a cryptographically secure stream b … of pseudo-random bits is obtained. The back door This algorithm is fatally flawed, as Ferguson and Shumow pointed out [Shumow-Ferguson]. Since P and Q are non-identity elements of a cyclic group of prime order, each is a multiple of the other. Write P = e * Q, for some integer e. We show that once we have e in hand, it is a simple matter to determine the secret internal state s of the pseudo-random bit generator by observing the output b, and thus to compromise the entire system. The function extract_bits discards 16 bits. Given the output b, we take the 2^{16} (a small number of) possible preimages t of b under extract_bits. For each t, the coordinate x is known, and solving a quadratic, there are at most two possibilities for the coordinate y of a point A on the elliptic curve such that t = x1 (A). One such A is r * Q. For each A, we compute e * A. One of the small number of possibilities for e * A is e * (r * Q) = r * (e * Q) = r * P. (1) Finally s’ = x1 (r * P). In short, the internal state s’ can be be narrowed down to a small number of possibilities by an examination of the pseudo-random output bitstream. Shumow and Ferguson state that in experiments, “32 bytes of output was sufficient to uniquely identify the internal state of the PRNG [pseudo-random number generator].” The back door to the algorithm is the number e such that P = e * Q. To use the back door, one must know of the value e. The NIST standard does not disclose e (of course!), and extensive cryptographic experience suggests that it is hard to compute e from the coordinates of P and Q (unless you happen to own a quantum computer). This is the problem of discrete logarithms. But starting with e, there is no difficulty in creating a pair P and Q. The back door is universal: a single number e gives back door access to the internal state of the algorithm of all users worldwide. It is a matter of public fact that the NSA was tightly involved in the writing of the standard. Indeed, NIST is required by law to consult with NSA in creating its standard. According to the New York Times, “classified NSA memos appear to confirm that the fatal weakness, discovered by two Microsoft cryptographers in 2007, was engineered by the agency” [NYT]. The news article goes on to say that “eventually, NSA became the sole editor” and then pushed aggressively to make this the standard for the 163 member countries of the International Organization for Standardization. Further historical and social context appears in [Wired]. NSA had facile access to the crown jewel e and motive to seize it. Draw your own conclusions. Observations 1. This back door to this algorithm is extremely elementary from a mathematical perspective. We wrote the essential algorithm in six lines of computer code, even if more supporting code is needed to make it industrial strength. The algorithm could be explained to undergraduate math majors, or sufficiently advanced high-school students. The story also has the spy-agency intrigue to make a good math club talk or a special lecture in an elementary abstract algebra course. We essentially just need to understand that an elliptic curve is an abelian group whose elements (other than the identity element) are determined by two numbers x and y, that y is the root of a quadratic when x is given, and that every non-identity element of a cyclic group of prime order is a generator. Easy stuff. 2. Without prior knowledge of the back door, how difficult would it be to rediscover the possible existence of a back door? An analysis of the argument shows the required level of creativity is that of an undergraduate homework problem. We must think to write the element P as a multiple of the generator Q in a cyclic group of prime order. This a student learns in the first weeks of undergraduate algebra. The rest of the process of inverting the pseudo-random number generator is determined by the definition of the function itself: simply take each step defining the function and reverse the steps, asking for the preimage of the function at each step of its definition, working from the output back to the secret state s’. Once the question of inverting the function is asked, it is easy to do the group theory, even if it is computationally difficult to write e explicitly. One-way functions are a standard tool in the cryptographer’s bag. Every professional who has been trained to analyze cryptographic algorithms knows to ask the question of invertibility. It is unsettling that NIST and others do not seem to have asked this basic question. Diffie-Hellman key exchange In what follows, let us assume that someone, whom we will call the Spy, has access to the back door e. How is it possible for the Spy and the end user (the User) of the NIST algorithm to come into possession of the same shared secret (the internal state of the pseudo-random number generator), when all communication between them is public? Information flows from the Spy to the User through the published NIST standard, and from the User back to the Spy through the public output of the pseudo-random generator. The back door must have a remarkable cryptographic design to permit a secret to pass across these public channels, yet prevent the secret from becoming known to a third party. As we now explain, the design of the back door to NIST is based on a well-known algorithm in cryptography called the Diffie-Hellman key exchange [Diffie-Hellman]. This is an algorithm to share a secret between two parties, when there is a possibility that the channel of communication is being monitored. In the current context, the Spy has full knowledge of the Diffie-Hellman key exchange for what it is. However, the User participates in the exchange innocently and unwittingly, by blindly following the rules of the NIST protocol. The Diffie-Hellman key exchange requires a group, which we will take to be a cyclic group E of order n (to preserve notation). The group E, its order n, and a generator Q are made public. To share a secret, the first party (the Spy), picks a random number e, which is kept secret, and publishes P = e * Q to the world. The second party (the User) picks a random number r, which is kept secret, and publishes r * Q. Then by Equation (1), the Spy who knows e and r *Q, and the User who knows r and e * Q can both compute (r e) * Q = r * P, which is the shared secret. (In our context, the shared secret determines the internal state s’ of the pseudo-random number generator.) If E is a group in which the public knowledge E, n, Q, P = e * Q, r * Q does not allow the easy computation of (r e) * Q, then the shared secret is protected from public disclosure by the difficulty of the computation. In this way, the only two who learn the internal state of the pseudo-random number generator are the Spy and the User. What we have described here is not an imaginary scenario: NIST documents do in fact publish the data E, n, Q, and P, needed to initiate the Diffie-Hellman exchange. A user, when making public the output from the pseudo-random number generator, does in fact complete the exchange. Diffie-Hellman is Diffie-Hellman, whether it has been advertised as such or not. To say that the Diffie-Hellman key exchange algorithm is well-known is a vast understatement. This algorithm is a significant lesson in virtually every first course in cryptography everywhere in the world. Building on Merkle, the Diffie-Hellman paper, by starting the entire field of public key cryptography, is one of the most influential papers in cryptography ever written. What is the significance of all this? It is no secret that the NSA employs some of the world’s keenest cryptographic minds. They all know Diffie-Hellman. In my opinion, an algorithm that has been designed by NSA with a clear mathematical structure giving them exclusive back door access is no accident, particularly in light of the Snowden documents. This is a work of experts. References [NIST] E. Barker and J. Kelsey, Recommendation for random number generation using deterministic random bit generators. NIST Special Publication 800-90A (2012), http://csrc.nist.gov/publications/nistpubs/800-90A/SP800-90A.pdf. [Diffie-Hellman] W. Diffie and M. Hellman, New directions in cryptography. IEEE Transactions on Information Theory 22 (1976), 644-654. [Luby] M. Luby, Pseudorandomness and cryptographic applications, Princeton University Press, 1996. [NYT] N. Perloth, J. Larson, and S. Shane. N.S.A. able to foil basic safeguards of privacy on web, September 5, 2013, New York Times, http://www.nytimes.com/2013/09/06/us/nsa-foils-much-internet-encryption.html. [Shumow-Ferguson] D. Shumow and N. Ferguson, On the possibility of a back door in the NIST SP800-90 dual EC PRNG, http://rump2007.cr.yp.to/15-shumow.pdf, 2007. [Wired] K. Zetter, How a crypto `backdoor’ pitted the tech world against the NSA, Wired (Sept 24, 2013), http://www.wired.com/threatlevel/2013/09/nsa-backdoor/

1 0

Re: Bitcoin mining efficiency and Botnets
by Bill Stewart 16 Oct '13

16 Oct '13

At 03:16 AM 10/15/2013, coderman wrote: >On Tue, Oct 15, 2013 at 3:03 AM, Cathal Garvey ><cathalgarvey(a)cathalgarvey.me> wrote: > > People focus too much on the "profit" miners make, and not the > > verifiability and anarchism they are supposed to be providing to the > > bitcoin network. > >this is why it is useful to run a bitcoind and contribute to the >network, even if you do not mine. Anarchism's a great thing, but if you're trying to run an actual economy, you need to make it workable for economic reasons, not just ideological ones. Now that mining takes actual work and non-trivial amounts of electricity, and there are enough bitcoins on the market that you can just buy them, people are only going to do it if they can make a profit. (If the market gets big enough that there aren't enough bitcoins circulating to meet demand, the price goes up, and maybe mining becomes profitable again.)

2 1

[liberationtech] NSA must be best informed entity regarding viagra market
by Eugen Leitl 16 Oct '13

16 Oct '13

Recipe for a DoS. ----- Forwarded message from Richard Brooks <rrb(a)acm.org> ----- Date: Tue, 15 Oct 2013 12:44:07 -0400 From: Richard Brooks <rrb(a)acm.org> To: liberationtech <liberationtech(a)lists.stanford.edu> Subject: [liberationtech] NSA must be best informed entity regarding viagra market Message-ID: <525D70D7.90501(a)acm.org> User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 Reply-To: liberationtech <liberationtech(a)lists.stanford.edu> Since most email is spam, how productive is the NSA dragnet? http://www.washingtonpost.com/blogs/the-switch/wp/2013/10/15/the-nsas-giant… -- Liberationtech is public & archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at companys(a)stanford.edu. ----- 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

2 1