- cypherpunks - lists.cpunks.org

Curious use of cpunks list [Brian Carroll]
by grarpamp 17 Oct '13

17 Oct '13

Please consider writing a whitepaper on the subject of whatever it is you're trying to say and then posting a link to it here with a one paragraph summary for readers. And if you are, or rather than, using this list (as previously surmised by others) as the rough equivalent of your own numbers station, there are surely better places to broadcast this material... nntp, a hidden service webpage, an actual numbers list (which you could ask the cpunks maintainer to set up). Curiosities are presumably welcome here, but really, this? The archives do not indicate much of an audience. Perhaps I've missed something? So I defer to any simple on topic summary and/or explanation which might move others to go back and digest it all for its suggested value and comment therein.

9 8

Re: Bitcoin mining efficiency and Botnets
by Softy 17 Oct '13

17 Oct '13

I hope others point this out, the cost of gold ( nor any other commodity ) is so simplisticly tied to the price of production. Without doing any googling for specific numbers: - the price rise of gold in the past decade. - is the production costs of mining gold getting more or less expensive? alright ... here are some numbers: total cost of production example: 670 per ounce need I quote the current price of gold per ounce? Note, that AISC is just one regions cost - others are plus or minus a hundred or so. http://www.trefis.com/stock/abx/articles/206888/an-analysis-of-barrick-gold… and in pretty pictures: http://www.visualcapitalist.com/what-is-the-cost-of-mining-gold It is the 'other factors' of commodities which drive prices. Biggest is the cartel which controls that particular commodity - think diamonds for easy picture, Read about Libor, ISD etc: http://www.rollingstone.com/politics/news/everything-is-rigged-the-biggest-… -daniel

2 1

Re: [Cryptography] "/dev/random is not robust"
by Eugen Leitl 16 Oct '13

16 Oct '13

----- Forwarded message from John Gilmore <gnu(a)toad.com> ----- Date: Mon, 14 Oct 2013 18:53:58 -0700 From: John Gilmore <gnu(a)toad.com> To: dj(a)deadhat.com Cc: tytso(a)mit.edi, Cryptography List <cryptography(a)metzdowd.com>, cryptography(a)randombit.net Subject: Re: [Cryptography] "/dev/random is not robust" Message-Id: <201310150153.r9F1rwqQ011302(a)new.toad.com> > http://eprint.iacr.org/2013/338.pdf I'll be the first to admit that I don't understand this paper. I'm just an engineer, not a mathematician. But it looks to me like the authors are academics, who create an imaginary construction method for a random number generator, then prove that /dev/random is not the same as their method, and then suggest that /dev/random be revised to use their method, and then show how much faster their method is. All in all it seems to be a pitch for their method, not a serious critique of /dev/random. They labeled one of their construction methods "robustness", but it doesn't mean what you think the word means. It's defined by a mess of greek letters like this: Theorem 2. Let n > m, , ?? ??? be integers. Assume that G : {0, 1}m ??? {0, 1}n+ is a deterministic (t, ??prg )- pseudorandom generator. Let G = (setup, refresh, next) be defined as above. Then G is a ((t , qD , qR , qS ), ?? ??? , ??)- 2 robust PRNG with input where t ??? t, ?? = qR (2??prg +qD ??ext +2???n+1 ) as long as ?? ??? ??? m+2 log(1/??ext )+1, n ??? m + 2 log(1/??ext ) + log(qD ) + 1. Yeah, what he said! Nowhere do they seem to show that /dev/random is actually insecure. What they seem to show is that it does not meet the "robustness" criterion that they arbitrarily picked for their own construction. Their key test is on pages 23-24, and begins with "After a state compromise, A (the adversary) knows all parameters." The comparison STARTS with the idea that the enemy has figured out all of the hidden internal state of /dev/random. Then the weakness they point out seems to be that in some cases of new, incoming randomness with mis-estimated entropy, /dev/random doesn't necessarily recover over time from having had its entire internal state somehow compromised. This is not very close to what "/dev/random is not robust" means in English. Nor is it close to what others might assume the paper claims, e.g. "/dev/random is not safe to use". John PS: After attending a few crypto conferences, I realized that academic pressures tend to encourage people to write incomprehensible papers, apparently because if nobody reading their paper can understand it, then they look like geniuses. But when presenting at a conference, if nobody in the crowd can understand their slides, then they look like idiots. So the key to understanding somebody's incomprehensible paper is to read their slides and watch their talk, 80% of which is often explanations of the background needed to understand the gibberish notations they invented in the paper. I haven't seen either the slides or the talk relating to this paper. _______________________________________________ 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

The NSA's New Code Breakers
by Eugen Leitl 16 Oct '13

16 Oct '13

(thank, John, worth reposting full-text) http://www.foreignpolicy.com/articles/2013/10/15/the_nsa_s_new_codebreakers… The NSA's New Code Breakers America's using front companies, break-in artists, and hacktivists to spy on everyone -- and only North Korea seems able to resist. BY MATTHEW M. AID | OCTOBER 15, 2013 There was a time when the code breakers of the National Security Agency actually took the lead in solving enemy encryption systems. These days, not so much. In today's NSA, it's hackers, break-in artists, corporate liaisons, and shadow salesman using front companies who are at the forefront of this effort. Even so-called "hacktivists" play an unwitting role in helping the NSA gain access to computer networks -- both hostile and friendly. Just about the only place that's somewhat immune to the NSA's new style of code-breaking attacks? North Korea, because it's so disconnected from the rest of the world's networks. Former U.S. intelligence officials confirm that the more than 1,500 cryptanalysts, mathematicians, scientists, engineers, and computer technicians who comprise NSA's elite cryptanalytic unit, the Office of Cryptanalysis and Exploitation Services (S31), have had a remarkably large number of code-breaking successes against foreign targets since the 9/11 attacks. But these wins were largely dependent on clandestine intelligence activities for much of their success in penetrating foreign communications networks and encryption systems, and not the more traditional cryptanalytic attacks on encrypted messages that were the norm during the Cold War era. Prior to 9/11, NSA's cryptanalysts used their huge stable of supercomputers to break cipher systems using what is referred to as "brute force methods" -- using the super computers to run every cipher permutation until the message or messages in question become readable. It was a long, tedious, and extremely costly process (today NSA spends over $247 million a year to buy and maintain its state-of-the-art supercomputer systems just for cryptanalytic use). But it did work if there were inherent vulnerabilities or structural weakness in the cipher being attacked, or if the system's users did not practice proper communications security procedures, such as changing the cipher keys and passwords frequently. The NSA today has more supercomputers than ever and the agency still employs a number of puzzle-solvers, linguists, and math geeks. But these classic cryptanalysts have, in part, given way to a new breed. You won't learn this in the files leaked by former NSA contractor Edward Snowden -- at least not directly. According to individuals who have reviewed the entire collection of 50,000 documents provided to the media by Snowden, what is missing from the papers is any document which lays out in detail just how successful the agency's code-breaking efforts have been. There are numerous documents in the Snowden collection describing individual NSA cryptologic programs, such as NSA's mostly unsuccessful multi-year effort to crack the encryption protection used by the anonymizer service Tor. But no reports describing the agency's cryptanalytic successes and failures have been found in the Snowden collection to date. Interviews with current and former intelligence officials conducted over the past two months have revealed that since 9/11, NSA's computer scientists, electronic engineers, software programmers, and collection specialists have been remarkably inventive in finding new and innovative ways to circumvent the protections supposedly offered by encryption systems by compromising them through clandestine means. Among these clandestine means are CIA and FBI "black bag jobs," as well as secret efforts by the U.S. intelligence community to interdict the shipment of advanced encryption technology to America's enemies around the world, inserting "back doors" into commercially-available computer, communications and encryption technologies which allow NSA to covertly access these systems without the users knowing it. But the most sensitive of these clandestine techniques, and by far the most productive to date, is to covertly hack into targeted computers and copy the documents and message traffic stored on these machines before they are encrypted, a process known within NSA as "Endpoint" operations. Responsibility for conducting these Endpoint operations rests with the computer hackers of NSA's cyberespionage unit, the Office of Tailored Access Operations (TAO). According to sources familiar with the organization's operations, TAO has been enormously successful over the past 12 years in covertly inserting highly sophisticated spyware into the hard drives of over 80,000 computer systems around the world, although this number could be much higher. And according to the sources, these implants are designed in such a way that they cannot be detected by currently available commercial computer security software. It has been suggested to me by a reliable source that "this is not an accident," with the insinuation being that many of the biggest commercially-available computer security software systems made in the United States and overseas have been compromised by NSA, either covertly or with the knowledge and consent of the companies that manufacture these systems. Former agency personnel confirm that in innumerable instances these TAO implants have allowed NSA's analysts to copy and read all of the unencrypted documents stored on the targeted computer's hard drive, as well as copy every document and email message produced and/or transmitted by the machine. But more importantly, TAO has helped NSA's cryptanalysts solve several hundred foreign government and commercial encryption systems because these spyware implants, if properly inserted into the computer, can covertly alter its security software as well as copy the encryption system's technical parameters, especially the system's encryption algorithm and access passwords, in a way that cannot be detected. These implants can compromise the encryption systems used by not only the targeted computer, but also all other computer systems that it communicates with using encryption technology. According to confidential sources familiar with TAO's operations, many of NSA's cryptanalytic "success stories" against high-priority targets such as Russia and the People's Republic of China in recent years have been the direct result of TAO's cyberespionage efforts. For example, sources confirm that much of what the U.S. intelligence community knows about China's computer hacking efforts against targets in the United States, Europe, and Asia stems from TAO's intelligence collection efforts since 2005, when TAO reportedly achieved a major technical breakthrough against a Chinese target. But TAO doesn't just spy on America's rivals. In 2012, the group reportedly compromised the encryption system used by an important G8 country to transmit sensitive diplomatic communications via satellite to its embassies around the world. The same is true with a number of countries in the Middle East and South Asia, including Egypt, Syria, Iran, and Pakistan, although the details of these successes are not yet known. And finally, sources report that TAO has successfully compromised the privacy protection systems currently used on a range of 4G cell phones and hand-held devices, thanks in large part to help from a major American telecommunications company. There are high-profile targets that have proven resistant to TAO's cyberespionage efforts over the years, however. For example, TAO has reportedly had virtually no success penetrating North Korean government computer systems or networks because there are so few of them and they are heavily protected from access to the outside world. Over time, TAO has become increasingly accomplished at its mission, thanks in part to the high-level cooperation that it secretly receives from the "big three" American telecommunications companies (AT&T, Verizon, and Sprint), most of the large U.S.-based internet service providers, and many of the top computer security software manufacturers and consulting companies. According to a February 2012 budget document (.pdf) published earlier this year by ProPublica, these companies "Insert vulnerabilities into commercial encryption systems, IT systems, networks, and endpoint communications devices used by targets" on behalf of TAO. TAO is also very active in the global computer security industry marketplace, using the CIA, Defense Intelligence Agency, and State Department to help it keep close tabs on the latest computer security devices and software systems being developed around the world. And while details are lacking, informed sources report that TAO has been active in covertly buying up commercially available "hacker tools" or spyware software systems from individuals and companies in the United States and overseas, particularly in Western Europe, to help facilitate its ever-growing computer network exploitation efforts. The extreme sensitivity of TAO's collection efforts has required the NSA to take extraordinary steps to try to disguise its computer hacking activities. For instance, current and former intelligence sources confirm that TAO increasingly depends on clandestine techniques, such as commercial cover, to hide its activities. TAO uses an array of commercial business entities, some of them proprietary companies established specifically for this purpose, to try to hide its global computer hacking activities from computer security experts in a maze of interlocking computer servers and command-and-control systems located in the United States and overseas that have no discernible link to NSA or the U.S. government. These sources also say that TAO gets a lot of help from politically-motivated hackers, or "hacktivists," who unintentionally help NSA by providing ideas to improve TAO's collection efforts. (Exactly which hacktivists have been particularly helpful, these sources wouldn't say.) Working closely with NSA's computer security experts at the NSA/CSS Threat Operations Center, TAO personnel perform detailed forensic post-mortem studies of every major successful computer penetration operation around the world. Some of these are pulled off by criminal outfits, some by government-backed groups, others by political actors. In each case, the agency's personnel looks for new techniques or procedures that they can use to get inside computer systems around the world. There is no question that TAO's future looked incredibly bright before the first newspaper articles began appearing in the British and American press in June 2013 based on documents leaked by Snowden. Now, industry sources familiar with TAO say that the organization's future prospects have dimmed somewhat. A number of foreign-based computer systems and IT networks that formerly were major producers of intelligence information for TAO have over the past three months changed security procedures and encryption systems, routed traffic to more secure computer nodes or servers, erected new firewalls, or have gone offline altogether. According to recent press reports, the Russian government for a time reverted back to using manual typewriters rather than commit sensitive information to their computer systems. And a number of European countries and Brazil have begun shifting their most sensitive data and communications traffic to secure networks that they hope will be resistant to NSA's intrusive surveillance activities. But this is, I am sure, just the tip of the iceberg. I have no doubt that the damage to TAO's foreign intelligence collection capabilities and its ability to facilitate the solution of foreign encryption systems by NSA's cryptanalysts has been substantial. The big question that will determine TAO's future prospects is whether the damage done so far proves to be irreparable.

1 0

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