- cypherpunks@lists.ogf.org

[tahoe-dev] Tahoe-LAFS, Tor and Tails
by Eugen Leitl 09 Aug '13

09 Aug '13

----- Forwarded message from Jacob Appelbaum <jacob(a)appelbaum.net> ----- Date: Fri, 09 Aug 2013 00:22:54 +0000 From: Jacob Appelbaum <jacob(a)appelbaum.net> To: tahoe-dev(a)tahoe-lafs.org, The Tails public development discussion list <tails-dev(a)boum.org> Subject: [tahoe-dev] Tahoe-LAFS, Tor and Tails Greetings from Berlin, Leif and I have been working on ways to deploy, use and sync data with Tahoe on Tails. Tails[0] is a live CD based on Debian GNU/Linux that is supported by the Tor Project. It is intended to lose state after every shutdown, unless a user configures it to keep certain bits of information in a so-called Persistent container. This is usually a LUKS encrypted partition on the same bootable medium that contains Tails. To start - we worked through bootstrapping Tahoe on a Tails system - the Tahoe package in Debian and thus available in Tails as of the Tails 0.19 release is 1.9.2-1. This is a bit older than we'd like, so we bootstrapped from source with only a few Debian packages from the packaging system. Here is the git repo for the script that we used to bootstrap Tahoe-LAFS on Tails 0.19: https://github.com/leif/tahoe-tails-utils The following ticket covers the overall issues of actually trying to bootstrap Tahoe safely on any network at all: https://tahoe-lafs.org/trac/tahoe-lafs/ticket/2055 The issues outlined in the above ticket should cover Tor users, though likely it equally applies to a VPN user, an i2p user and really, anyone barebacking with the internet. Once this bootstrapping process was completed, we connected the Tails machine to a Tahoe-LAFS grid that is Tor aware. The introducer runs as a Tor hidden service. Each of the Storage Nodes also presents their respective addresses as Tor hidden services through the previously mentioned introducer. We found that the open browser command uses the system browser included with Tails. We weren't thrilled about the main browser being used for local system daemon or system service related activities. I dislike that it talks to the loopback interface, while other content it loads may go over the Tor network or even try to do other things with stored data in the browser or on the file system. This ticket is an example of why total browser isolation is a good idea: https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1942 We prefer that at least this browser data should be isolated from any other web browsing I might perform with this machine. We wrote a quick little hack to use a different profile - we added a wrapper called `tahoe-browser` written in bash and stuffed it into /usr/local/bin/tahoe-browser. We then set BROWSER in the environment to point to it: export BROWSER="/usr/local/bin/tahoe-browser" This allows me to use `tahoe webopen grid-news/Latest/index.html` in a completely separate browser profile. Hooray. What is grid-news? A useful news service on our local Tor grid - any url would have the same issues as noted. Is this useful? Should we generalize this and add it to Tahoe? It would be easy enough to extend src/allmydata/scripts/tahoe_webopen.py to do this job with the addition of another small class. No such tahoe-browser program would be required - though it surely wouldn't hurt to keep them completely separated. An interesting trick would be to put that browser profile itself inside of a user's Tahoe grid. It would provide some on-the-go anti-forensics and keep all Tahoe related url data, bookmarks and so on inside of the grid itself. Leif isn't so hot on this idea because of Tahoe's Magic Folders idea isn't implemented. Abstractly, I like the idea but I'm not sure if it is practical. As it stands, we've now managed to bootstrap Tahoe on Tails - so it is basically possible to do all grid related activity over Tor. We don't have to worry about exit nodes as we're using Tor Hidden Services for all of the services. Though generally, I'm not really worried about Tor Exit nodes in the context of Tahoe-LAFS. In an ideal world, we'd use the Tails persistence feature to store a user's Tahoe's introducer furl and a few other important bits. This could then in turn be used to store all of the other Tails persistance data - things like web browser history, .{ssh,gnupg,pidgin,etc}, and/or even added Debian packages. To do this, we need to add persistence support for Tahoe related configuration in Tails and we need to ensure that Tahoe ships as part of Tails. Here are a few bugs related to this in the Tails bug tracker: https://labs.riseup.net/code/issues/5514 https://labs.riseup.net/code/issues/5804 Adding '/home/amnesia/.tahoe' to the Tails persistence seems to be possible from an existing Tails system. We've filed a bug to add this discuss adding Tahoe as a default option in the persistence configuration dialog: https://labs.riseup.net/code/issues/6227 There are a few interesting improvements that came up for discussion during this process. One such idea relates to changing the way that the Storage Nodes publish data to introducers. Wouldn't it be nice if we could reduce the authority of the introducer even more? With a little bit of effort, we could ensure that an attacker who learns about the introducer is only able to learn the number of Storage Servers but not any other information. For an all Tor Hidden Service grid with such an introducer, an attacker who takes the introducer will learn very little beyond a rough count of the total Storage Nodes connecting to that introducer. The clients are all protected by Tor and the Storage Nodes are similarly protected by Tor. The Storage Nodes would stay not only geographically anonymous as provided by Tor but it wouldn't be possible to learn their .onion names and even begin to have any way to connect with them at all. To do this, we'd need to encrypt the furls shared by the introducer in some way. This requires that clients share a symmetric key or publish a public key or something similar. Thus the introducer could even be shared by a few groups who do not trust each other. If we merge the multi-introducer patch, heavily used by the i2p folks, we could really do interesting things along these lines. These ideas obviously require a design that is beyond the scope of this email. Additionally, we thought it useful to extend Tahoe to be aware of a grid that uses Tor Stealth Hidden Services[1][2]. This essentially adds a layer of authentication between a client and a server at the Tor layer. Thus even if an attacker were to learn of a Storage Nodes's .onion, without the corresponding shared secret - no one will be able to connect to the Storage node or even elicit a reply from that server. This is a bit tricky in the sense that the Storage Node will make outbound connections to the introducer - so Tahoe Storage Node client side exploitation is probably a concern. However, if an introducer were stolen, the Storage Node's .onion would not be useful to the attacker without the Tor Hidden Service authorization keys. Those keys should only be available on the Tahoe client's Tor client, and the Tor Hidden Service Storage Server's Tor client and not on the introducer. We of course want to ensure that Tails has the newest version of Tahoe - though there is some debate about using Tahoe-LAFS or Leif's Truckee Tahoe-LAFS branch. Any thoughts on this topic would be appreciated. What else should we be thinking about? All the best, Jacob [0] https://tails.boum.org/ [1] https://www.torproject.org/docs/tor-hidden-service.html.en [2] https://www.torproject.org/docs/hidden-services.html.en _______________________________________________ tahoe-dev mailing list tahoe-dev(a)tahoe-lafs.org https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-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

<nettime> Statement: Why Secure Email Provider Lavabit closes down
by Eugen Leitl 09 Aug '13

09 Aug '13

----- Forwarded message from nettime's paranoid reader <nettime(a)kein.org> ----- Date: Fri, 09 Aug 2013 10:57:45 +020§ From: nettime's paranoid reader <nettime(a)kein.org> To: nettime-l(a)mx.kein.org Subject: <nettime> Statement: Why Secure Email Provider Lavabit closes down Reply-To: a moderated mailing list for net criticism <nettime-l(a)mail.kein.org> http://lavabit.com My Fellow Users, I have been forced to make a difficult decision: to become complicit in crimes against the American people or walk away from nearly ten years of hard work by shutting down Lavabit. After significant soul searching, I have decided to suspend operations. I wish that I could legally share with you the events that led to my decision. I cannot. I feel you deserve to know what?s going on--the first amendment is supposed to guarantee me the freedom to speak out in situations like this. Unfortunately, Congress has passed laws that say otherwise. As things currently stand, I cannot share my experiences over the last six weeks, even though I have twice made the appropriate requests. What?s going to happen now? We?ve already started preparing the paperwork needed to continue to fight for the Constitution in the Fourth Circuit Court of Appeals. A favorable decision would allow me resurrect Lavabit as an American company. This experience has taught me one very important lesson: without congressional action or a strong judicial precedent, I would _strongly_ recommend against anyone trusting their private data to a company with physical ties to the United States. Sincerely, Ladar Levison Owner and Operator, Lavabit LLC Defending the constitution is expensive! Help us by donating to the Lavabit Legal Defense Fund here [1]. [1] https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=7BCR4A… # 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

Getting started
by stakewinner00 08 Aug '13

08 Aug '13

Hi, I'm 16 years old and I was searching in duckduckgo and Google for some material about cypherpunks but I not find nothing more than this mailing list and some deserted website. If someone can give me some more information, I would be very grateful. Sorry for my bad English and for the spam.

12 12

Urea at NSA Utah Data Center
by John Young 08 Aug '13

08 Aug '13

There are two spaces labeled "Urea Tank Room" in the NSA Utah Data Center's Generator Plant shown in construction drawings recently leaked: http://cryptome.org/2013-info/07/nsa-utah-dc/nsa-utah-dc.htm See Generator Plant floor plan drawing 11.2 A101 at bottom and top left, spaces labeled "UT." Urea is used in fuel cells. Are there other uses of urea in generator or data processing equipment?

6 6

Malware Keylogger
by Yush Bhardwaj 08 Aug '13

08 Aug '13

Guys I was trying to setup a pendrive as malware which works for all OS (Windows/Linux/Mac). I know how to do it for windows but I am still searching to get my setup done for mac and linux. Any her knows anything about it * * * * * * *Yush Bhardwaj*

2 1

Re: [cryptography] a Cypherpunks comeback
by Bill Stewart 08 Aug '13

08 Aug '13

>On Mon, Jul 22, 2013 at 3:41 AM, Adam Back <adam(a)cypherspace.org> wrote: > > Could you please get another domain name, that name is just ridiculous. Absolutely. I mean, has anybody actually used JFETs in recent years? :-)

6 8

[cryptography] fwd: Paillier Crypto
by Eugen Leitl 07 Aug '13

07 Aug '13

----- Forwarded message from dan(a)geer.org ----- Date: Mon, 05 Aug 2013 14:43:28 -0400 From: dan(a)geer.org To: cryptography(a)randombit.net Subject: [cryptography] fwd: Paillier Crypto > http://9ac345a5509a.github.io/p2p-paillier/ > > This is a form of Homomorphic Encryption that might actually scale, > given the right cloud backend. It verges on the spookiness of > Quantum. > > Support logic that might shed light on the true performance of > Paillier. > > http://plaintext.crypto.lo.gy/article/658/encounter --dan _______________________________________________ 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

3 4

Re: [liberationtech] Tormail in trouble. Experts at Black Hat recommend Elliptic Curves: this is what PassLok 1.3 is based on.
by Eugen Leitl 07 Aug '13

07 Aug '13

----- Forwarded message from Gregory Maxwell <gmaxwell(a)gmail.com> ----- Date: Tue, 6 Aug 2013 15:39:29 -0700 From: Gregory Maxwell <gmaxwell(a)gmail.com> To: liberationtech <liberationtech(a)lists.stanford.edu> Subject: Re: [liberationtech] Tormail in trouble. Experts at Black Hat recommend Elliptic Curves: this is what PassLok 1.3 is based on. Reply-To: liberationtech <liberationtech(a)lists.stanford.edu> On Tue, Aug 6, 2013 at 3:20 PM, Francisco Ruiz <ruiz(a)iit.edu> wrote: > Hi folks, > > Thank you very much for your great feedback on the previous version. The > next version is now up at http://passlok.com, which redirects to > https://passlok.site44.com > This may come in handy now that there are problems with Tor, since PassLok > allows you to go to any computer to do encrypted mail, because there is > nothing to install. This is what PassLok was designed to do. > > The other unforeseen endorsement came from the recent Black Hat conference. > Researchers Alex Stamos, Tom Ritter, Thomas Ptacek, and Javed Samuel > encouraged everyone to base their public key cryptosystems on elliptic > curves rather than RSA. Here's a link on this: > http://arstechnica.com/security/2013/08/crytpo-experts-issue-a-call-to-arms… Wait. You are using vague popular press FUD about RSA to promote a website hosted JS encryption tool? Really? Your code generates random values like this: sjcl.random.addEntropy([a.x || a.clientX || a.offsetX || 0, a.y || a.clientY || a.offsetY || 0], 2, "mouse") sjcl.random.addEntropy((new Date).valueOf(), 2, "loadtime") try { var s = new Uint32Array(32); crypto.getRandomValues(s); sjcl.random.addEntropy(s, 1024, "crypto['getRandomValues']") } catch (t) {} Meaning that if it's used someplace where crypto.getRandomValues() doesn't exist, it has only pure snake-oil-extract randomness. Really???? If the randomness is poor, the nonce used in ECDSA will be predictable and the private key will be recoverable. This isn't to say I've audited any of it, I just grepped for a couple likely mistakes. Part of the JS code has been whitespace compressed, I consider it unauditable. > up to a whopping > 200,000 iterations for lousy keys. Since keys made in version 1.2 are no > longer compatible, this prompts upping the version to 1.3. So, not implemented in slow-as-dirt JS 200,000 iterations should take a random desktop cpu about 100ms or so. This is hardly wopping. It's not far from the minimum I'd start with, for all keys not just weak ones. Generally user provided keys are a security disaster and should be avoided wherever it's possible, strengthening or no. Humans are horrific entropy sources and really can't self assess how bad they are. -- Liberationtech list is public and archives are searchable on Google. Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at companys(a)stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech ----- 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: [liberationtech] Anonymity Smackdown: NSA vs. Tor
by Eugen Leitl 07 Aug '13

07 Aug '13

----- Forwarded message from Roger Dingledine <arma(a)mit.edu> ----- Date: Wed, 7 Aug 2013 03:05:35 -0400 From: Roger Dingledine <arma(a)mit.edu> To: liberationtech <liberationtech(a)mailman.stanford.edu> Subject: Re: [liberationtech] Anonymity Smackdown: NSA vs. Tor User-Agent: Mutt/1.5.20 (2009-06-14) Reply-To: liberationtech <liberationtech(a)lists.stanford.edu> On Tue, Aug 06, 2013 at 10:43:39PM -0500, Kyle Maxwell wrote: > The key, obviously, is the primary assertion that the NSA runs "lots" > of Tor nodes. I've seen this assertion before, and while it's > certainly a reasonable assumption, I don't know if anybody outside the > NSA actually has hard evidence for that. I remember having this discussion with Bruce Schneier long ago, when he was about to add the phrase "of *course* NSA runs Tor relays" to a blog post. Consider two scenarios. In scenario one, NSA doesn't run any Tor relays, but they have done deals with AT&T and other networks to be able to passively monitor those networks -- including the (honest, well-intentioned) Tor relays that run on those networks. They're able to monitor some fraction of the Tor network capacity -- whether that's 1% or 10% or 30% is a fine question, and depends on both Internet topology and also what deals they've done. In scenario two, they do that plus also run some relays. They have to deal with all the red tape of deploying and operating real-world things on the Internet, and the risk that they'll do it wrong, somebody will notice, etc. And the benefit is maybe a few percent increase in what they can watch. Why would they choose scenario two? Scenario one seems like it would be working out pretty well for them. And if it's not, their resources would be better spent fixing that, since it leads to better surveillance of everything else they care about too. See https://lists.torproject.org/pipermail/tor-talk/2013-July/028851.html for a related discussion. Oh, and this argument should also lead you to ask "ok, but what about <smaller country that hasn't yet been reported to have a huge Internet surveillance program>? Shouldn't they run relays?" Maybe they should. Maybe we should hope they all do, which could make the network more diverse assuming they don't share well with each other. > Assuming that assertion holds, the architectural criticisms start to > matter more: 3 hops, 1024 bit RSA keys, etc. Somebody should tell Robert about the recent (Tor 0.2.4.x) shift to much stronger circuit handshakes and link encryption: https://gitweb.torproject.org/tor.git/blob/refs/tags/tor-0.2.4.15-rc:/Chang… https://gitweb.torproject.org/tor.git/blob/refs/tags/tor-0.2.4.15-rc:/Chang… And for the "Multiple apps share the same underlying Tor egress" concern, he should learn about the stream isolation features added in Tor 0.2.3.x: https://gitweb.torproject.org/tor.git/blob/refs/tags/tor-0.2.4.15-rc:/Chang… All of this said, I don't want anybody to conclude that Tor is perfect. Many of the attacks from my 25c3 "security and anonymity vulnerabilities in Tor" talk remain hard research questions: https://media.torproject.org/video/ --Roger -- Liberationtech list is public and archives are searchable on Google. Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at companys(a)stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech ----- 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

Former NSA Boss Calls Snowden's Supporters Internet Shut-ins; Equates Transparency Activists With Al-Qaeda
by Tony Arcieri 07 Aug '13

07 Aug '13

Suddenly the al-qaeda.net domain is seeming more appropriate. Apparently we're terrorists because we like Snowden! https://www.techdirt.com/articles/20130806/12154724080/former-nsa-director-… -- Tony Arcieri

1 0