- cypherpunks - lists.cpunks.org

Bradley Manning's sentence: 35 years for exposing us to the truth
by Shelley 22 Aug '13

22 Aug '13

http://www.theguardian.com/commentisfree/2013/aug/21/bradley-manning-senten… Bradley Manning's sentence: 35 years for exposing us to the truth This was never a fair trial – Obama declared Manning's guilt in advance. But Manning's punishment is an affront to democracy Birgitta Jónsdóttir theguardian.com, Wednesday 21 August 2013 10.29 EDT Jump to comments (…) Link to video: Bradley Manning: 35 years in jail for an outsider who had trouble fitting in – video As of today, Wednesday 21 August 2013, Bradley Manning has served 1,182 days in prison. He should be released with a sentence of time served. Instead, the judge in his court martial at Fort Meade, Maryland has handed down a sentence of 35 years. Of course, a humane, reasonable sentence of time served was never going to happen. This trial has, since day one, been held in a kangaroo court. That is not angry rhetoric; the reason I am forced to frame it in that way is because President Obama made the following statements on record, before the trial even started: President Obama: We're a nation of laws. We don't individually make our own decisions about how the laws operate … He broke the law. Logan Price: Well, you can make the law harder to break, but what he did was tell us the truth. President Obama: Well, what he did was he dumped … Logan Price: But Nixon tried to prosecute Daniel Ellsberg for the same thing and he is a … [hero] President Obama: No, it isn't the same thing … What Ellsberg released wasn't classified in the same way. When the president says that the Ellsberg's material was classified in a different way, he seems to be unaware that there was a higher classification on the documents Ellsberg leaked. A fair trial, then, has never been part of the picture. Despite being a professor in constitutional law, the president as commander-in-chief of the US military – and Manning has been tried in a court martial – declared Manning's guilt pre-emptively. Here is what the Pentagon Papers leaker Daniel Ellsberg had to say about this, in an interview with Amy Goodman at DemocracyNow! in 2011: Well, nearly everything the president has said represents a confusion about the state of the law and his own responsibilities. Everyone is focused, I think, on the fact that his commander-in-chief has virtually given a directed verdict to his subsequent jurors, who will all be his subordinates in deciding the guilt in the trial of Bradley Manning. He's told them already that their commander, on whom their whole career depends, regards him [Manning] as guilty and that they can disagree with that only at their peril. In career terms, it's clearly enough grounds for a dismissal of the charges, just as my trial was dismissed eventually for governmental misconduct. But what people haven't really focused on, I think, is another problematic aspect of what he said. He not only was identifying Bradley Manning as the source of the crime, but he was assuming, without any question, that a crime has been committed. This alone should have been cause for the judge in the case to rethink prosecutors' demand for 60 years in prison. Manning himself has shown throughout the trial both that he is a humanitarian and that he is willing to serve time for his actions. We have to look at his acts in light of his moral compass, not any political agenda. Manning intentions were never to hurt anyone; in fact, his motivation – as was the case for Ellsberg – was to inform the American public about what their government was doing in their name. A defense forensic psychiatrist testified to Manning's motives: Well, Pfc Manning was under the impression that his leaked information was going to really change how the world views the wars in Afghanistan and Iraq, and future wars, actually. This was an attempt to crowdsource an analysis of the war, and it was his opinion that if … through crowdsourcing, enough analysis was done on these documents, which he felt to be very important, that it would lead to a greater good … that society as a whole would come to the conclusion that the war wasn't worth it … that really no wars are worth it. I admit that I share the same hopes that drove Manning to share with the rest of the world the crimes of war he witnessed. I am deeply disappointed that no one has been held accountable for the criminality exposed in the documents for which Manning is standing trial – except him. It shows so clearly that our justice systems are not working as intended to protect the general public and to hold accountable those responsible for unspeakable crimes. I want to thank Bradley Manning for the service he has done for humanity with his courage and compassionate action to inform us, so that we have the means to transform and change our societies for the better. I want to thank him for shining light into the shadows. It is up to each and everyone of us to use the information he provided for the greater good. I want to thank him for making our world a little better. This is why I nominated him for the Nobel Peace Prize, for there are very few individuals who have ever brought about the kind of social change Manning has put in motion. The wave of demands for greater transparency, more accountability, and democratic reform originate with Manning's lonely act in the barracks in Iraq. He has given others – such as Edward Snowden – the courage to do the right thing for the rest of us. The heavy hand dealt Bradley Manning today is a massive blow against everything many of us hold sacred – at a time when we have been shown how fragile and weak our democracies are by the revelations of, first, Manning, and now, Snowden. There is no such thing as privacy anymore; nor is there such a thing as accountability among our public servants. Our governments do not function for the benefit of the 99%. If Manning had received a fair sentence that was in proportion to his supposed crime – which was to expose us to the truth – then there would have been hope. Instead, we are seeing the state acting like a wounded tiger, cornered and lashing out in rage – attacking the person who speaks the truth in order to frighten the rest of us into silence. But to that, I have only one answer: it won't work.

1 0

Re: [tor-talk] encrypted mailing lists
by Eugen Leitl 21 Aug '13

21 Aug '13

----- Forwarded message from Lunar <lunar(a)torproject.org> ----- Date: Wed, 21 Aug 2013 10:43:59 +0200 From: Lunar <lunar(a)torproject.org> To: tor-talk(a)lists.torproject.org Subject: Re: [tor-talk] encrypted mailing lists User-Agent: Mutt/1.5.21 (2010-09-15) Reply-To: tor-talk(a)lists.torproject.org Matej Kovacic: > I believe we should ask Mailman developers to include that functionality > in the future releases. > > What do you think? Please look at the SSLS patch if you want to stick to Mailman: <http://non-gnu.uvt.nl/mailman-ssls/> Schleuder has a small but growing userbase: <https://schleuder2.nadir.org/> It is available in Debian and counts Tails as one of its users. (This is getting off-topic for tor-talk.) -- Lunar <lunar(a)torproject.org> -- 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

[tor-talk] Tor Weekly News — August, 21st 2013
by Eugen Leitl 21 Aug '13

21 Aug '13

----- Forwarded message from Lunar <lunar(a)torproject.org> ----- Date: Wed, 21 Aug 2013 14:29:40 +0200 From: Lunar <lunar(a)torproject.org> To: tor-talk(a)lists.torproject.org, tor-news(a)lists.torproject.org Subject: [tor-talk] Tor Weekly News — August, 21st 2013 User-Agent: Mutt/1.5.21 (2010-09-15) Reply-To: tor-talk(a)lists.torproject.org ======================================================================== Tor Weekly News August 21st, 2013 ======================================================================== Welcome to the eighth issue of Tor Weekly News, the weekly newsletter that covers what is happening in the great Tor community. Future of pluggable transports integration ------------------------------------------ While David Fifield was busy updating the Pluggable Transports Bundle to match the “classic” bundle version 0.2.4.16-beta-1 [1], several discussions took place on how to better integrate pluggable transports in the future. bastik opened #9444 [2], pointing out that “currently TBB with Pluggable Transports are build separately, thus lagging behind”. Having two separate bundles is also a long standing usability issue, as often users have tried to add “obfs” bridges to their normal TBB [3]. Mike Perry is fully aware of the issue and stated in the discussion that his “long term goal is to try to cram all of the pluggable transports into The One True Bundle.” This will require modifications to the new “Tor Launcher” component of the TBB 3.x series in order to allow users to select the bridges and pluggable transports they wish to use. Compromises might be needed on how users should input bridges. BridgeDB recently stopped having the “bridge” keyword in front of the addresses it replies [4] with as Vidalia would not understand it. Mike Perry was thinking in exactly the opposite direction: “take bridge lines directly from bridgedb […] verifying only that they start with ‘bridge’”. Maybe the transition could be easier if Florian Stinglmayr’s patch to Vidalia [5] was merged so that current bundles would ignore the “bridge” keyword when entering bridges [6]. In any case, Mike wants to solve these issues “before we release as beta/stable, to minimize user confusion.” Another tricky part of the “One True Bundle” solution is the bundle size, making it harder to circumvent download restrictions through email [7]. But, as Mike said, “even if they don’t, we’ll probably have to find some other solution anyway for gettor, because the intersection of gettor users and PT users is probably high.” [1] https://www.torproject.org/docs/pluggable-transports.html.en [2] https://bugs.torproject.org/9444 [3] https://bugs.torproject.org/9156 [4] https://gitweb.torproject.org/user/isis/bridgedb.git/commit/792cfd9 [5] https://github.com/n0la/vidalia/tree/master-bug/6724 [6] https://bugs.torproject.org/6724 [7] https://www.torproject.org/projects/gettor.html Extended ORPort land in tor 0.2.5 --------------------------------- After more than a year and a half in the making, the Extended ORPort mechanism [8] has been merged by Nick Mathewson into the tor master branch [9]. This will allow pluggable transport proxies to exchange arbitrary operational information and metadata with tor clients and bridges. Such plumbing was needed in order to make some pluggable transports easier to use or to allow Tor to gather more data about the state of the transports used. obfsproxy has supported this new communication channel [10] for a little while and was only waiting for tor to catch up. George Kadianakis thus asked obfsbridge operators to upgrade their tor to git master to enable client statistics [11]. Once they do, their bridges will send statistics on users per transport to the bridge authority, and they will be published on metrics.torproject.org [12]. This helps track deployment of pluggable transports in the future. [8] https://gitweb.torproject.org/torspec.git/blob/HEAD:/proposals/196-transpor… [9] https://gitweb.torproject.org/tor.git/commit/74262f15 [10] https://gitweb.torproject.org/pluggable-transports/obfsproxy.git/blob/HEAD:… [11] https://lists.torproject.org/pipermail/tor-relays/2013-August/002477.html [12] https://metrics.torproject.org/users.html?graph=userstats-bridge-transport&… A new implementation for the web side of check.torproject.org ------------------------------------------------------------- Arlo Breault wrote a new implementation for the web component of check.torproject.org in the Go programming language [13], in response to Roger Dingledine’s appeal: “Check could really use some love. Any volunteers please?”. [14,15] There is already a ticket to replace the check.torproject.org servers with Arlo’s Go version [16]. Andrew Lewman stated again that “As for check.tpo website, it shouldn’t exist at all”, as it is an architectural issue to “have the entire tor browser userbase hit a single website to learn ’Tor or not’”. Until all clients are changed to stop using check, deploying a new code base would only make sense if it was at least able to handle “500 requests per second on really busy times”. More benchmarks are probably needed with Arlo’s implementation. On another front, tup, the initial author of TorDNSEL [17], has resurfaced to offer [18] to update the code to work with newer Haskell environments after many years of silence! [13] https://github.com/arlolra/check/ [14] https://lists.torproject.org/pipermail/tor-talk/2013-August/029306.html [15] https://bugs.torproject.org/9529 [16] https://gitweb.torproject.org/tordnsel.git/commit/99d490 [17] https://bugs.torproject.org/9204#comment:14 Tor exit crowdfunding --------------------- Moritz Bartl from torservers.net [18] posted an update [19] on their ongoing crowdfunding campaign to support Tor exit bandwidth. The fund just went over €3000, and there are still a few days left! For more information, and ways to contribute, please visit the Indiegogo page [20]. [18] https://www.torservers.net/ [19] https://lists.torproject.org/pipermail/tor-talk/2013-August/029431.html [20] http://www.indiegogo.com/projects/tor-anti-censorship-and-anonymity-infrast… A Flattr-like incentive for Tor relays? --------------------------------------- While torservers.net is presently collecting euros, George Kadianakis asked for comments from the Tor community about “a practical crowdfunded Flattr-like incentive scheme for Tor relays”, dubbed Flattor [21]. George’s proposal is meant to solve “one of the problems of scaling Tor to tens of millions of users”, that “Tor’s bandwidth capacity is finite”. He observes that “lately the bandwidth coming out of Tor-friendly organizations (like torservers.net, universities, etc.) seems to increase” and is worried that “Tor might end up looking like the Bitcoin network — where a number of organizations (mining pools) drive the network.” What George would like to see is incentives for contributing to the network. After studying schemes proposed in the past, all deemed “hard to implement and deploy”, George proposes a simple approach: users can opt to spend a fixed amount of bitcoins to support the Tor network, and their donation will be divided according to the bandwidth of each relay. Obviously, relay operators who wish to receive such contributions would need to publish a bitcoin address, probably in the “contact” field. There might be some concerns with such scheme, or any monetary incentives scheme, as George summarized: “If relay operators start getting money for their bandwidth, we might end up with relay operators that are just in for the money. It might then be easier for a three-letter org to persuade those relay operators to snoop on their users (by giving them double the money they are currently getting).” Moritz Bartl commented [22] that the idea was already quite close to torservers.net current plan, to the extent that donations were distributed “across all participating organizations based on […] advertised bandwidth and a country-specific factor.” Moritz also pointed out that similar discussions had already happened in the past when a sponsor wished to fund faster exit relays [23]. George concluded his mail by saying that he is “not even sure if such an incentive scheme is a good idea, but posting bad ideas to mailing lists is what the Internet is for, right?” Feel free to join the discussion, or hack wildly. [21] https://lists.torproject.org/pipermail/tor-talk/2013-August/029419.html [22] https://lists.torproject.org/pipermail/tor-talk/2013-August/029421.html [23] https://blog.torproject.org/blog/turning-funding-more-exit-relays Miscellaneous news ------------------ The new release of Orbot 12.0.3 comes with a shiny new icon and graphics, bugfixes, and Tor 0.2.4.16-rc. You can download the update via Google Play [24] or straight from Guardian Project’s website [25]. [24] https://play.google.com/store/apps/details?id=org.torproject.android [25] https://guardianproject.info/releases/orbot-latest.apk Andrew Lewman has published the financial reports of the Tor Project for the year 2012 [26]. [26] https://blog.torproject.org/blog/transparency-openness-and-our-2012-financi… Arturo has sent his report for July 2013 [27]. [27] https://lists.torproject.org/pipermail/tor-reports/2013-August/000313.html Runa Sandvik reported on her trip to Black Hat & DEF CON [28]. She managed to fill “the Penn & Teller theater (~1500 people)” for a talk [29] about “the safety of the Tor network which focused on network diversity, relay operators, and misbehaving relays.” The former Tor GSoC student Brandon Wiley also gave an update [30] on Dust — “an Internet protocol designed to resist a number of attacks currently in active use to censor Internet communication.” [31] [28] https://lists.torproject.org/pipermail/tor-reports/2013-August/000312.html [29] https://www.defcon.org/html/defcon-21/dc-21-speakers.html#Sandvik [30] https://www.defcon.org/html/defcon-21/dc-21-speakers.html#Wiley [31] https://github.com/blanu/Dust/ Karsten Loesing has made progress on “experimenting with a client and private bridge connected over uTP” [32]. The connection can be established, but strange timing issues remain to be solved. [32] https://trac.torproject.org/projects/tor/ticket/9166#comment:23 George Kadianakis has sent two new proposals to improve hidden service identity key security [33] and prevent address enumeration [34]. TWN will cover these proposals in detail once the draft deployment strategy is published. Feel free to help refine the proposals in the meantime! [33] https://lists.torproject.org/pipermail/tor-dev/2013-August/005279.html [34] https://lists.torproject.org/pipermail/tor-dev/2013-August/005280.html Help Desk Roundup ----------------- Users experience confusion when trying to update the Tor Browser Bundle. Users are not always aware that the Tor Browser Bundle does not have an autoupdate function. Some users will download the latest release from the Tor Project website, then ask “Ok, what do I do now?”. We recommend closing the browser, then deleting one’s current Tor Browser folder before unpacking the new download. One person asked for help while using the Pirate Browser. Torrent-sharing website The Pirate Bay released the Pirate Browser this week as a fork of the Tor Browser Bundle. The Pirate Browser is not endorsed or recommended by the Tor Project. It is unclear what the advantages are compared to using the Tor Browser Bundle and no source code is available. This issue of Tor Weekly News has been assembled by Lunar, dope457, malaparte, mttp, Karsten Loesing, and harmony. 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 [35], write down your name and subscribe to the team mailing-list [36] if you want to get involved! [35] https://trac.torproject.org/projects/tor/wiki/TorWeeklyNews [36] 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] Preventing Time Correlation Attacks on Leaks: Help! :-)
by Eugen Leitl 21 Aug '13

21 Aug '13

----- Forwarded message from Ben Laurie <ben(a)links.org> ----- Date: Wed, 21 Aug 2013 05:51:38 -0400 From: Ben Laurie <ben(a)links.org> To: "Fabio Pietrosanti (naif)" <lists(a)infosecurity.ch> Cc: Crypto discussion list <cryptography(a)randombit.net> Subject: Re: [cryptography] Preventing Time Correlation Attacks on Leaks: Help! :-) On 21 August 2013 03:35, Fabio Pietrosanti (naif) <lists(a)infosecurity.ch>wrote: > Hey Peter, > > thanks for your analysis! > > I think we need to provide some additional input! > > In the context of GlobaLeaks where, stating from our Threat Model at > https://docs.google.com/document/d/1niYFyEar1FUmStC03OidYAIfVJf18ErUFwSWCmW…, the Whistleblower can also be NON anonymous but approach a submission > with "Confidential" level (over HTTPS over the internet) . > > No anonymity, but forced disclaimer ( > https://github.com/globaleaks/GlobaLeaks/issues/260) and acceptance to > take the risk. > > So, let's say that whistleblower is already in a bad position, but he > accepted this condition. > > We are not considering in any way to add actions/protection on > Whistleblower-Side but only on Receiver-Side that is where the "bad guy" > would be able to read Notification information sent and apply Time > Correlation on the Whistleblower-Action. > > Today if a Whistleblower make a submission, the system immediatelly send a > notification to the Receiver. > > That's bad, because it leave a trace that allow time correlation. > > Who can read Receiver's email and traffic, can make a correlation on other > data source where the whistleblower may leave traffic-traces (like a proxy, > but also internet traffic dump, phisical badge/access logs, surveillance > camera, etc) . > > Which kind of logic / algorithm to apply on the Receiver's notification > timing in order to prevent / reduce the likelihood that a time correlation > pattern is possible? > > A random delay between a lower bounday and an upper boundary seems like > the most simple and effective approach to defeat this kind of correlation. > > However this does not work on very low-traffic globaleaks node. > > What do you think? > I think that if you want to send messages that are hard to trace, there's an existing technology: mixmaster, with an existing server network. Or, better yet, finish off mixminion, Even better: implement Minx (the fixed version). > > > -- > Fabio Pietrosanti (naif) > HERMES - Center for Transparency and Digital Human Rightshttp://logioshermes.org - http://globaleaks.org - http://tor2web.org > > > > Il 8/21/13 4:17 AM, Peter Maxwell ha scritto: > > > Hi Fabio, > > While I don't mean to be dismissive, I suspect your threat model is > flawed for the following reasons: > > i. Most mid to large companies would not permit the use of Tor within > their infrastructure and even if the hypothetical company did, it doesn't > take a whole lot of effort to track down the handful of users within a > company using Tor/stunnel/ssh/VPN. For that matter, I understand some > companies even install private CA certificates into the browsers on company > computers and decrypt outgoing SSL/TLS traffic at their > web-proxy/firewall... in that situation, you're WB is going to stand out > like a sore thumb as they'll be the only TLS connection that isn't being > decrypted (because it's Tor). So unless you want your whistle-blowers to > literally advertise their presence as worthy of attention, they aren't > going to do the leak from an company system directly. > > ii. So, presuming i. is valid - and I suspect anyone who has worked > within a competent security operations team will tell you the same - then > you must assume the whistle-blower will do the leak from either their > personal systems, a burn computer or a public system. If we make the > assumption that the WB has taken the data out of the company/organisation > on removable media or otherwise made it available to themselves outside the > company infrastructure in a secure manner (while sometimes difficult, that > is still far easier than i.) then your attacker can only see the WB's > traffic if they are actively monitoring the WB's use of computers outside > the company, in which case said WB has far bigger problems to worry about. > If the attacker cannot monitor the timing of the leak, your problem is not > framed in the manner you've presented. > > iii. Even if your model was realistic, you cannot adequately defend > against traffic analysis for such a low-traffic network: you need other > traffic to hide in, lots of it, from other users within the same company - > it's not realistic for this type of service. > > iv. There are more subtle problems you are going to come across, not > least of which are issues such as document tagging/water-marking/document > versioning and the ability for the attacker - your hypothetical manager - > to correlate leaked documents against the access rights and access patterns > of potential whistle-blowers. For that matter, simple forensic analysis of > staff computers is usually more than sufficient (and yes, organisations do > this). > > > It's also Isle of Man that people like hiding their ill-gotten-gains in, > not "Island of Mann" ;-) Interestingly, I think anyone who has used Isle > of Man accounts for tax avoidance are scuppered as the HMRC has signed an > agreement with the authorities there for automatic disclosure. > > > Anyway, as far as I can see it, you have two different scenarios to > consider with one being significantly more difficult to solve than the > other: > > > A. The scenario where the whistle-blower is able to take the data out > the company on removable media or paper-copy. This is the easy one to > solve. Personally I would favour a combination of asymmetric encryption > with single-use keypairs and USB sticks in the post, but I'm old fashioned > that way. > > B. The scenario where the whistle-blower has to leak from the > company/organisation's network. This is extremely difficult indeed. If I > were approaching this problem myself, my first considerations would be: how > to make the traffic look like normal web-traffic; how to ensure no forensic > traces are left; and how to do that without installation of third-party > software as that is a dead give-away. If the quantity of data is larger > than a few hundred Mb, the problem is probably not solvable. > > > That's my tuppence-worth, hope that helps, > > Peter > > > > > _______________________________________________ > cryptography mailing list > cryptography(a)randombit.net > http://lists.randombit.net/mailman/listinfo/cryptography > > _______________________________________________ cryptography mailing list cryptography(a)randombit.net http://lists.randombit.net/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

[drone-list] German activists drone NSA complex
by Eugen Leitl 21 Aug '13

21 Aug '13

----- Forwarded message from Gregory Foster <gfoster(a)entersection.org> ----- Date: Tue, 20 Aug 2013 17:29:46 -0500 From: Gregory Foster <gfoster(a)entersection.org> To: drone-list <drone-list(a)lists.stanford.edu> Subject: [drone-list] German activists drone NSA complex User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 Reply-To: drone-list <drone-list(a)lists.stanford.edu> A Parrot AR.Drone sortie over a German NSA complex from a nearby activist picnic last month. YouTube (Jul 22) - "Dagger Complex - Directors Cut": http://www.youtube.com/watch?v=SOjJ3BM1pt0 via @marymad, gf -- Gregory Foster || gfoster(a)entersection.org @gregoryfoster <> http://entersection.com/ -- Want to unsubscribe? Want to receive a weekly digest instead of daily emails? Change your preferences: https://mailman.stanford.edu/mailman/listinfo/drone-list or email 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

1 0

Groklaw shuts down
by Riad S. Wahby 21 Aug '13

21 Aug '13

http://www.groklaw.net/article.php?story=20130818120421175 " My personal decision is to get off of the Internet to the degree it's possible. I'm just an ordinary person. But I really know, after all my research and some serious thinking things through, that I can't stay online personally without losing my humanness, now that I know that ensuring privacy online is impossible. I find myself unable to write. I've always been a private person. That's why I never wanted to be a celebrity and why I fought hard to maintain both my privacy and yours. " -=rsw

6 6

Google to encrypt cloud storage
by rysiek 21 Aug '13

21 Aug '13

OHAI, PRISM caused a ot of fear but now we can finally feel safe again -- Google will encrypt all Google Drive storage with user-supplied keys: http://it.slashdot.org/story/13/08/16/239253/ So our data will be perfectly safe with them, right? Right?.. ;) Seriously, though, this is very, very bad for us. Normals will point to that and say "hey, Google does the Right Thing and we can be safe there, so we should all use Google now. They have encryption and stuff." -- Pozdr rysiek

8 18

Changing IP address to access public website ruled violation of US law
by rysiek 21 Aug '13

21 Aug '13

Hi there, You have probably already heard about that, but... Changing IP address to access public website ruled violation of US law: http://arstechnica.com/tech-policy/2013/08/changing-ip-address-to-access-pu… -- Pozdr rysiek

2 2

Re: [cryptography] LeastAuthority.com announces PRISM-proof storage service
by Eugen Leitl 21 Aug '13

21 Aug '13

----- Forwarded message from ianG <iang(a)iang.org> ----- Date: Sat, 17 Aug 2013 11:52:58 +0300 From: ianG <iang(a)iang.org> To: cryptography(a)randombit.net Subject: Re: [cryptography] LeastAuthority.com announces PRISM-proof storage service User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 On 16/08/13 22:11 PM, zooko wrote: > On Tue, Aug 13, 2013 at 03:16:33PM -0500, Nico Williams wrote: >> >> Nothing really gets anyone past the enormous supply of zero-day vulns in their complete stacks. In the end I assume there's no technological PRISM workarounds. > > I agree that compromise of the client is relevant. My current belief is that > nobody is doing this on a mass scale, pwning entire populations at once, and > that if they do, we will find out about it. > > My goal with the S4 product is not primarily to help people who are being > targeted by their enemies, but to increase the cost of indiscriminately > surveilling entire populations. > > Now maybe it was a mistake to label it as "PRISM-Proof" in our press release > and media interviews! I said that because to me "PRISM" means mass surveillance > of innocents. Perhaps to other people it doesn't mean that. Oops! My understanding of PRISM is that it is a voluntary & secret arrangement between the supplier and the collector (NSA) to provide direct access to all information. By 'voluntary' I mean that the supplier hands over the access, it isn't taken in an espionage or hacker sense, or leaked by an insider. I include in this various techniques of court-inspired voluntarianism as suggested by recent FISA theories [0]. I suspect it is fair to say that something is PRISM-proof if: a) the system lacks the capability to provide access b) the operator lacks the capacity to enter into the voluntary arrangement, or c) the operator lacks the capacity to keep the arrangement (b) secret The principle here seems to be that if the information is encrypted on the server side without the keys being held or accessible by the supplier, then (a) is met [1]. Encryption-sans-keys is an approach that is championed by Tahoe-LAFS and Silent Circle. Therefore I think it is reasonable in a marketing sense to claim it is PRISM-proof, as long as that claim is explained in more detail for those who wish to research. In this context, one must market ones product, and one must use simple labels to achieve this. Otherwise the product doesn't get out there, and nobody is benefited. iang [0] E.g., the lavabit supplier can be considered to have not volunteered the info, and google can be considered to have not volunteered to the Chinese government. [1] In contrast, if an operator is offshore it would meet (b) and if an operator was some sort of open source distributed org where everyone saw where the traffic headed, it would lack (c). > Regards, > > Zooko > > _______________________________________________ > cryptography mailing list > cryptography(a)randombit.net > http://lists.randombit.net/mailman/listinfo/cryptography > _______________________________________________ cryptography mailing list cryptography(a)randombit.net http://lists.randombit.net/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

[cryptography] Reply to Zooko (in Markdown)
by Eugen Leitl 20 Aug '13

20 Aug '13

----- Forwarded message from Jon Callas <jon(a)callas.org> ----- Date: Fri, 16 Aug 2013 23:04:38 -0700 From: Jon Callas <jon(a)callas.org> To: Zooko Wilcox-OHearn <zooko(a)leastauthority.com> Cc: cryptography(a)randombit.net Subject: [cryptography] Reply to Zooko (in Markdown) X-Mailer: Apple Mail (2.1508) -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Also at http://silentcircle.wordpress.com/2013/08/17/reply-to-zooko/ # Reply to Zooko (My friend and colleague, [Zooko Wilcox-O'Hearn](https://leastauthority.com/blog/author/zooko-wilcox-ohearn.html) wrote an open letter to me and Phil [on his blog at LeastAuthority.com](https://leastauthority.com/blog/open_letter_silent_circ…. Despite this appearing on Silent Circle's blog, I am speaking mostly for myself, only slightly for Silent Circle, and not at all for Phil.) Zooko, Thank you for writing and your kind words. Thank you even more for being a customer. We're a startup and without customers, we'll be out of business. I think that everyone who believes in privacy should support with their pocketbook every privacy-friendly service they can afford to. It means a lot to me that you're voting with your pocketbook for my service. Congratulations on your new release of [LeastAuthority's S4](https://leastauthority.com) and [Tahoe-LAFS](https://tahoe-lafs.org/trac/tahoe-lafs). Just as you are a fan of my work, I am an admirer of your work on Tahoe-LAFS and consider it one of the best security innovations on the planet. I understand your concerns, and share them. One of the highest priority tasks that we're working on is to get our source releases better organized so that they can effectively be built from [what we have on GitHub](https://github.com/SilentCircle/). It's suboptimal now. Getting the source releases is harder than one might think. We're a startup and are pulled in many directions. We're overworked and understaffed. Even in the old days at PGP, producing effective source releases took years of effort to get down pat. It often took us four to six weeks to get the sources out even when delivering one or two releases per year. The world of app development makes this harder. We're trying to streamline our processes so that we can get a release out about every six weeks. We're not there, either. However, even when we have source code to be an automated part of our software releases, I'm afraid you're going to be disappointed about how verifiable they are. It's very hard, even with controlled releases, to get an exact byte-for-byte recompile of an app. Some compilers make this impossible because they randomize the branch prediction and other parts of code generation. Even when the compiler isn't making it literally impossible, without an exact copy of the exact tool chain with the same linkers, libraries, and system, the code won't be byte-for-byte the same. Worst of all, smart development shops use the *oldest* possible tool chain, not the newest one because tool sets are designed for forwards-compatibility (apps built with old tools run on the newest OS) rather than backwards-compatibility (apps built with the new tools run on older OSes). Code reliability almost requires using tool chains that are trailing-edge. The problems run even deeper than the raw practicality. Twenty-nine years ago this month, in the August 1984 issue of "Communications of the ACM" (Vol. 27, No. 8) Ken Thompson's famous Turing Award lecture, "Reflections on Trusting Trust" was published. You can find a facsimile of the magazine article at <https://www.ece.cmu.edu/~ganger/712.fall02/papers/p761-thompson.pdf> and a text-searchable copy on Thompson's own site, <http://cm.bell-labs.com/who/ken/trust.html>. For those unfamiliar with the Turing Award, it is the most prestigious award a computer scientist can win, sometimes called the "Nobel Prize" of computing. The site for the award is at <http://amturing.acm.org>. In Thompson's lecture, he describes a hack that he and Dennis Ritchie did in a version of UNIX in which they created a backdoor to UNIX login that allowed them to get access to any UNIX system. They also created a self-replicating program that would compile their backdoor into new versions of UNIX portably. Quite possibly, their hack existed in the wild until UNIX was recoded from the ground up with BSD and GCC. In his summation, Thompson says: The moral is obvious. You can't trust code that you did not totally create yourself. (Especially code from companies that employ people like me.) No amount of source-level verification or scrutiny will protect you from using untrusted code. In demonstrating the possibility of this kind of attack, I picked on the C compiler. I could have picked on any program-handling program such as an assembler, a loader, or even hardware microcode. As the level of program gets lower, these bugs will be harder and harder to detect. A well installed microcode bug will be almost impossible to detect. Thompson's words reach out across three decades of computer science, and yet they echo Descartes from three centuries prior to Thompson. In Descartes's 1641 "Meditations," he proposes the thought experiment of an "evil demon" who deceives us by simulating the universe, our senses, and perhaps even mathematics itself. In his meditation, Descartes decides that the one thing that he knows is that he, himself, exists, and the evil demon cannot deceive him about his own existence. This is where the famous saying, "*I think, therefore I am*" (*Cogito ergo sum* in Latin) comes from. (There are useful Descartes links at: <http://www.anselm.edu/homepage/dbanach/dcarg.htm> and <http://en.wikipedia.org/wiki/Evil_demon> and <http://en.wikipedia.org/wiki/Brain_in_a_vat>.) When discussing thorny security problems, I often avoid security ratholes by pointing out Descartes by way of Futurama and saying, "I can't prove I'm not a head in a jar, but it's a useful assumption that I'm not." Descartes's conundrum even finds its way into modern physics. It is presently a debatable, yet legitimate theory that our entire universe is a software simulation of a universe . Martin Savage of University of Washington <http://www.phys.washington.edu/~savage/> has an interesting paper from last November on ArXiV <http://arxiv.org/pdf/1210.1847v2.pdf>. You can find an amusing video at <http://www.huffingtonpost.com/2012/12/24/universe-computer-simulation_n_233…> in which Savage even opines that our descendants are simulating us to understand where they came from. I suppose this means we should be nice to our kids because they might have root. Savage tries to devise an experiment to show that you're actually in a simulation, and as a mathematical logician I think he's ignoring things like math. The problem is isomorphic to writing code that can detect it's on a virtual machine. If the virtual machine isn't trying to evade, then it's certainly possible (if not probable -- after all, the simulators might want us to figure out that we're in a simulation). Unless, of course, they don't, in which case we're back not only to Descartes, but Godel's two Incompleteness Theorems and their cousin, The Halting Problem. While I'm at it, I highly, highly recommend Scott Aaronson's new book, "Quantum Computing Since Democritus" <http://www.scottaaronson.com/democritus/> which I believe is so important a book that I bought the Dead Tree Edition of it. ([Jenny Lawson](http://thebloggess.com) has already autographed my Kindle.) Popping the stack back to security, the bottom line is that you're asking for something very, very hard and asking for a solution to an old philosophical problem as well as suggesting I should prove Godel wrong. I'm flattered by the confidence in my abilities, but I believe you're asking for the impossible. Or perhaps I'm programmed to think that. This limitation doesn't apply to just *my* code. It applies to *your* code, and it applies to all of us. (Tahoe's architecture makes it amazingly resilient, but it's not immune.) It isn't just mind-blowing philosophy mixed up with Ken Thompson's Greatest Hack. Whenever we run an app, we're trusting it. We're also trusting the operating system that it runs on, the random number generator, the entropy sources, and so on. You're trusting the CPU and its microcode. You're trusting the bootloader, be it EFI or whatever as well as [SMM](http://en.wikipedia.org/wiki/System_Management_Mode) on Intel processors -- which could have completely undetectable code running, doing things that are scarily like Descartes's evil demon. The platform-level threats are so broad that I could bore people for another paragraph or two just enumerating them. You're perhaps trusting really daft things like [modders who slow down entropy gathering](http://hackaday.com/2013/01/04/is-entropy-slowing-down-your-andr… and [outright bugs](http://android-developers.blogspot.com/2013/08/some-securerandom-thou…. Ironically, the attack vector you suggest (a hacked application) is one of the harder ways for an attacker to feed you bad code. On mobile devices, apps are digitally signed and delivered by app stores. Those app stores have a vetting process that makes *targeted* code delivery hard. Yes, someone could hack us, hack Google or Apple, or all of us, but it's very, very hard to deliver bad code to a *specific* person through this vector, and even harder if you want to do it undetectably. In contrast, targeted malware is easy to deploy. Exploits are sold openly in exploit markets, and can be bundled up in targeted advertising. Moreover, this *has* happened, and is known to be a mechanism that's been used by the FBI, German Federal Police, the Countries Starting With the Letter 'I' (as a friend puts it), and everyone's favorite The People's Liberation Army. During Arab Spring, a now-defunct government just procured some Javascript malware and dropped it in some browsers to send them passwords on non-SSL sites. Thus, I think that while your concern does remind me to polish up my source code deployment, if we assume an attacker like a state actor that targets people and systems, there are smarter ways for them to act. I spend a lot of time thinking, "*If I were them, what would I do?*" If you think about what's possible, you spend too much time on low-probability events. Give yourself that thought experiment. Ask yourself what you'd do if you were the PLA, or NSA, or a country starting with an 'I.' Give yourself a budget in several orders of magnitude. A grand, ten grand, a hundred grand, a million bucks. What would you do to hack yourself? What would you do to hack your users without hacking you? That's what I think about. Over the years, I've become a radical on usability. I believe that usability is all. It's easy to forget it now, but PGP was a triumph because you didn't have to be a cryptographer, you only had to be a techie. We progressed PGP so that you could be non-technical and get by, and then we created PGP Universal which was designed to allow complete ease of use with a trusted staff. That trusted staff was the fly in the ointment of Silent Mail and the crux of why we shut it down -- we created it because of usability concerns and killed it because of security concerns. Things that were okay ideas in May 2013 were suddenly not good ideas in August. I'm sure you've noted when using our service our belief in usability. Without usability that is similar to the non-secure equivalent, we are nothing because the users will just not be secure. I also stress Silent Circle is a *service*, not an app. This is hard to remember and even we are not as good at it as we need to be. The service is there to provide its users with a secure analogue of the phone and texting apps they're used to. The difference is that instead of having utterly no security, they have a very high degree of it. Moreover, our design is such to minimize the trust you need to place in us. Our network includes ourselves as a threat, which is unusual. You're one of the very few other people who do something similar. We have technology and policy that makes an attack on *us* to be unattractive to the adversary. You will soon see some improvements to the service that improve our resistance to traffic analysis. The flip side of that, however, is that it means that the device is the most attractive attack point. We can't help but trust the OS (from RNG to sandbox), bootloader, hardware, etc. Improvements in our transparently (like code releases) compete with tight resources for improvements in the service and apps. My decisions in deploying those resources reflect my bias that I'd rather have an A grade in the service with a B grade in code releases than an A in code releases and a B service. Yes, it makes it harder for you and others, but I have to look at myself in the mirror and my emphasis is on service quality first, reporting just after that. Over time, we'll get better. We've not yet been running for a year. Continuous improvement works. I'm going to sum up with the subtitle of the ACM article of Ken Thompson's speech. It's not on his site, but it is on the facsimile article: To what extent should one trust a statement that a program is free of Trojan horses? Perhaps it is more important to trust the people who wrote the software. Thank you very much for your trust in us, the people. Earning and deserving your trust is something we do every day. Regards, Jon -----BEGIN PGP SIGNATURE----- Version: PGP Universal 3.2.0 (Build 1672) Charset: us-ascii wj8DBQFSDxJ+sTedWZOD3gYRAiDiAJ0bR0EOetfQpPSTDtWX1qyn6wcIcACfbi5Z M9oM0D1yL77QHaw6RnEEFIU= =7StS -----END PGP SIGNATURE----- _______________________________________________ cryptography mailing list cryptography(a)randombit.net http://lists.randombit.net/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