- cypherpunks - lists.cpunks.org

NSA Today on Missions, Authorities, Oversight, Partnershps
by John Young 10 Aug '13

10 Aug '13

NSA statement today on Missions, Authorties, Oversight, Partnerships: http://cryptome.org/2013/08/nsa-13-0809.pdf

3 2

Re: [cryptopolitics] Silent Circle and Secure Email
by Adam Back 10 Aug '13

10 Aug '13

(Thanks for the link.) It says hushmail had a simplified web-only version (no java applet) and that the disclosure of client emails did not involve pressured code changes (at least code shipped to clients), rather that as a natural consequence of the way passwords would be processed on the server side and decryption happened on the server side so hushmail had the passwords, private keys, and decrypted plaintexts at leas in memory to hand over on request. Adam On Fri, Aug 09, 2013 at 08:59:… [View More]

1 0

Re: [cryptopolitics] Silent Circle and Secure Email
by Adam Back 10 Aug '13

10 Aug '13

Reading what Jon Callas wrote he said silent circle interoperated with unencrypted SMTP email (unencrypted other than SSL over the transport), and they used some bump in the wire PGP thingy that encrypts incoming email with the silent circle users public key, and presumably sends out cleartext possibly SSL SMTP where available, for non silent-circle recipients. Clearly therefore anyone tampering with the SSL (and often those mail transport systems are not that smart about SSL as there is no … [View More]

1 0

Nuclear Weapons Control Systems and NATO Super-Radar shut down by occupy group NOMOUS at NISCEMI, SICILY Re: [cryptome] NSA Today on Missions, Authorities, Oversight, Partnershps
by Wilfred Guerin 09 Aug '13

09 Aug '13

Nuclear Weapons Control Systems and NATO Super-Radar shut down by occupy group NOMOUS at NISCEMI, SICILY On Fri, Aug 9, 2013 at 10:14 AM, John Young <jya(a)pipeline.com> wrote: > NSA statement today on Missions, Authorties, Oversight, Partnerships: > > http://cryptome.org/2013/08/**nsa-13-0809.pdf<http://cryptome.org/2013/08/nsa-13-0809.pdf> > > > >

1 0

Breaking PRISM and friends
by Nick Thomas 09 Aug '13

09 Aug '13

Hi all, Only a decade or two late to the party... anyway, in the past few days since the PRISM / XKeyscore / etc leaks came to my attention, I've been considering schemes that breaks the kind of passive, drag-net collection of communications data from listening points on submarine cables and the like. I think I've found one, so I thought I'd share. Code is in very, very early stages at the moment; https://github.com/lupine/hide-eid has half of a first pass, and a bit of documentation on … [View More]why it might work. I'm hoping to have it in a state where you could run a pair of VPN providers servicing a few customers each within a few days. As-is, scalability is suspect, though. The short how-it-works is that it stops the IP header (which typically reveals who is talking to whom, even if the IP payload is encrypted) from being personally-identifying information. If your access ISP runs it, and your hosting ISP runs it too, you benefit from an anonymity set equal to all the source's customers. As long as there's no sniffing going on in the first and last mile, anyway. Combined with IPsec on those miles, or a vetted path if it's short enough, you can reduce the amount of cable that personally-identifying IP headers are sniffable on, from a few thousand miles, to perhaps a couple of feet - on which you can focus CCTV, if you're *really* paranoid; or even nothing at all, if you have the same box terminating the IPsec tunnel and the hide-eid wrapper/unwrapper. The theoretical background is from the location/identity separation protocol stuff. Intermediaries don't actually need to know which person (well, EID) the packet is from, or for; they just need to know where to send it (which RLOC) so that a person can pick it up. This scheme is basically that, imagined as a least-effort overlay on the existing IP network. And it doesn't break as many protocols as cgNAT, since source and destination both know the EID of destination and source. Feedback of any sort is extremely welcome. Particular areas of concern are scaling it (especially given how the crypto works), how the crypto works and if there's a more sensible way (key exchange with M:N different ISPs to take advantage of symmetric ciphers is worrisome), and whether there's a better way to get L/ISP with hidden EIDs deployed to a subset of the internet than a hack of this magnitude. I'm still fairly skeptical that it can make a noticeable difference, but it seems promising enough for me to keep it up in the short term, at least. If it ends up being useless, there's still tor. There's always tor. /Nick [View Less]

3 4

Re: The Guardian: Fears over NSA surveillance revelations endanger US cloud computing industry
by John Young 09 Aug '13

09 Aug '13

This fear of US cloud service was deployed against US crypto back then. Exemplified in the CryptoAG revelation. Then it was "revealed," as now, the competitors were even more devious. Meanwhile all of the spies and contractors got more funding to spy on each other and PR the mil-grade security, backslapping at how easy it was to spook the public, you know, spook as in spy on to assure freaking was effective. In 2000 it was "revealed" that CIA and NSA with the joint Special Collection Service, … [View More]

1 0

The Guardian: Fears over NSA surveillance revelations endanger US cloud computing industry
by Neil Johnson 09 Aug '13

09 Aug '13

http://www.theguardian.com/world/2013/aug/08/nsa-revelations-fears-cloud-co… -- Neil Johnson

1 0

Re: [tor-talk] Secure email with limited usable metadata
by Eugen Leitl 09 Aug '13

09 Aug '13

----- Forwarded message from coderman <coderman(a)gmail.com> ----- Date: Fri, 9 Aug 2013 00:39:03 -0700 From: coderman <coderman(a)gmail.com> To: tor-talk(a)lists.torproject.org Subject: Re: [tor-talk] Secure email with limited usable metadata Reply-To: tor-talk(a)lists.torproject.org On Mon, Jul 1, 2013 at 10:10 PM, coderman <coderman(a)gmail.com> wrote: > ... > my contempt for email should be evident by provider; ... ;) > [OTR, ZRTP, others preferable many … [View More]

3 2

[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 … [View More]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 [View Less]

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 … [View More]

1 0