Re: [liberationtech] Guardian reporter delayed e-mailing NSA source because crypto is a pain
Let's first have context -- at this time I am a 30 year old journalist. But (to establish my geek bona fides) shortly after I could legally drive, but long before I could vote, I went through the process of becoming a registered Debian Linux developer. Then, as is the case now, to achieve that status, one needs to have their GnuPG key (back then PGP) signed by a fellow developer who has verified their identity. While I had undergone the process with my PGP key back when I was a high school student, by the time Debian made the switch to GPG (as I recall for ideological reasons surrounding PGP's license) I was at university with far less free time, and learning crypto software or getting your keys exchanged and signed wasn't easy. And so I never made the time to learn the new software until recent events led me to revisit my options. I haven't been a regular Linux user since 2001 (switched to Apple) but I've tried available tools for Linux and what's out there for Mac OS, even trying to compile some F/OSS solutions from scratch on Mac OS. And to be honest, despite all the innovations in user interface over the past 12 years, the situation doesn't look to have changed much since 2001. Now, I realize that for someone whose very life might depend on strong encryption that works, their incentive to learn even the most arcane and user-unfriendly software could be high enough to overcome any resistance due to either inertia, poor design, or any other conceivable reason why Joe Public wouldn't make everyday use of the stuff. These days I'm a journalist, and while my work has rarely taken me into places or subjects where encryption is needed, recent events have inspired me to venture back into the available tools to see if I could make using email with strong cryptography easy enough that I could suggest it to regular sources for everyday use. It still sucks. What exists is godawful at worse and cumbersome at best. For a cryptosystem to really, and I mean really become widespread enough to make an impact, it needs to be designed and implemented in such a way that a given user who wants to add that level of security to his** email need only install at the very least some manner of plugin to an existing client, or at most switch to an easy to use replacement which has that functionality built in seamlessly. Key exchange would have to be as easy as forming connections on a social network. Heck, a crypto-social network might be the best way to jump-start such a thing. But let's be honest here -- I think we all are aware on some level or another that even if one was able to develop and deploy the easiest software imaginable (say, Apple's iCrypt that they'd allowed to be vetted, even made key parts open source) and the most robust algorithms known to man, it's not enough that it be easy to use -- it has to become widely adopted, at least among enough of the population that assuming easy key exchange, it would become a non-event for someone to send or receive an encrypted message. It would have to definitely be widespread enough that, if we also assume pervasive surveillance -- at least on a passive filtering level of some kind -- that to see cyphertext being transmitted back and forth would be common enough that it wouldn't raise alarms or attract attention of any sort. Let's get real -- assuming surveillance is the new normal, isn't it more likely that cyphertext in the datastream is -- at least as of this day and time -- more likely to attract attention from authorities than say, quality steganography or something like a carefully designed and well executed book code? Maybe the idea of pervasive surveillance and any resulting discomfort will raise interest in easy encryption among the general public, but given the state of the current crypto toolbox, I doubt it. Andrew **for those who are PC-inclined, please note I use his alone not out of misogyny but for brevity and clarity. On Jun 11, 2013, at 9:56 PM, Kate Krauss ka...@critpath.org wrote: It's really easy to use these tools if you already know how to do it. Otherwise they are often complicated and unintuitive. For some of us, they represent an academic field or a fascinating hobby. For others, they are the keys to survival. Hubris--and not really caring whether they work or not for non-geeks--is an obstacle to security. Most activists and journalists don't care how interesting these tools are, as long as they can get them to work. If they were as simple and stupid as AOL circa 2000, that would be great. This is the beauty of cryptoparties--people can sit next to you and talk you through it. Thanks, Asher Wolf. That is often all it takes. Otherwise, tiny glitches or misunderstandings can put them out of reach. A security workshop my group organized a couple years ago included lots of geeks ANDS lots of on-the-ground activists (of many stripes, including
[liberationtech] Global Principles on National Security Whistleblower
Hi all, this email to share the today release of the The Global Principles on National Security and Freedom of Information (the Tshwane Principles) by the Open Society Foundation. That's a set of Policy Guidelines for the protection of National Security Whistleblower. Those Principles address the topic of Whistleblowing and National Security and has been done in cooperation with 22 organizations: http://www.opensocietyfoundations.org/publications/global-principles-national-security-and-freedom-information-tshwane-principles As a summary i suggest reading Understanding the Tshwane Principles: http://www.opensocietyfoundations.org/briefing-papers/understanding-tshwane-principles It is very interesting to note that Snowden, the Whistleblower of NSA PRISM saga, would had been protected under Principles 43 and 46 (and maybe under Principle 40). A blog post with an analysis on the case related to that principles is being prepared. For media and analysts interested on it, they may contact sandra.coli...@opensocietyfoundations.org and jonathan.birch...@opensocietyfoundations.org . Regards, -- Fabio Pietrosanti (naif) HERMES - Center for Transparency and Digital Human Rights http://logioshermes.org - http://globaleaks.org - http://tor2web.org -- Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech
Re: [liberationtech] the Blackberry and Surveillance?
I haven`t been watching that closely but in the course of my following the current discussions on surveillance I have yet to see a reference to RIM/Blackberry... Is this because it`s recent loss of market share means it isn`t of particular interest (I would have thought the up to recent user demographics would rather make it of particular interest), because of some features which put it outside of the current surveillance stream, have I missed it in the current discussion, other? Tks, Mike -- Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech
Re: [liberationtech] Guardian reporter delayed e-mailing NSA source because crypto is a pain
This all rings very true for me: I'm a legal academic, and barely a geek, and in reality I barely ever use crypto. I was at the Privacy Law Scholars Conference in Berkeley last week when the PRISM story broke, and we had a special session at the end of the conference to talk about what we knew - and someone asked about 'user-friendly crypto' and there was a kind of laugh/cheer around the room. Everyone knows we want it, no-one believes it's there. Paul On 12 Jun 2013, at 09:27, Andy Isaacson a...@hexapodia.org wrote: On Tue, Jun 11, 2013 at 07:11:49PM -0700, Gregory Maxwell wrote: On Tue, Jun 11, 2013 at 6:56 PM, Kate Krauss ka...@critpath.org wrote: It's really easy to use these tools if you already know how to do it. I've been using PGP since 1994, if not earlier. In more recent times 1998, here. it's become a regular part of my workflow in discussing security critical bugs. I am a programmer and a computing expert. I use gnupg daily. I do not consider the tools easy to use at all ... I routinely, and frequently, still get bitten by design bugs, implementation bugs, and UI bugs which continue to make the PGP ecosystem effectively unusable. I cannot recommend PGP for routine use to anyone outside of the security community, and I don't think I know anyone who has used it consistently for more than 2 years without encountering a serious data/comms loss due to PGP bugs or gotchas. -andy -- Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech -- Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech
Re: [liberationtech] Guardian reporter delayed e-mailing NSA source because crypto is a pain
On Wed, Jun 12, 2013 at 06:15:30AM -0400, Sheila Parks wrote: Why not use her instead of his? Using his in 2013 is, indeed, misogyny List moderator, please control this before it completely goes out of hand. People are trying to get work done here, and this is not helping. -- Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech
Re: [liberationtech] Guardian reporter delayed e-mailing NSA source because crypto is a pain
warning: plugging my wares [1] (again). On 12-06-13 10:05, Andrew Feinberg wrote: What exists is godawful at worse and cumbersome at best. For a cryptosystem to really, and I mean really become widespread enough to make an impact, it needs to be designed and implemented in such a way that a given user who wants to add that level of security to his** email need only install at the very least some manner of plugin to an existing client, or at most switch to an easy to use replacement which has that functionality built in seamlessly. Key exchange would have to be as easy as forming connections on a social network. Heck, a crypto-social network might be the best way to jump-start such a thing. plugI've come up with something that might fit your requirements. Technobabble: Users can create an cryptographic identity at the click of the mouse. With the verification methods I describe at the project site, it allows for man in the middle detection and prevention. His user agent takes care of all the crypto-details. User sees: he creates an account at a (web) site by requesting an account name to be his. No need for email addresses, or identity validation that CA's do. You can test it by downloading (or compiling) the user agent [2] and contact me at 'guidow@@dating.wtmnd.nl'. [3] /plug But let's be honest here -- I think we all are aware on some level or another that even if one was able to develop and deploy the easiest software imaginable (say, Apple's iCrypt that they'd allowed to be vetted, even made key parts open source) and the most robust algorithms known to man, it's not enough that it be easy to use -- it has to become widely adopted, at least among enough of the population that assuming easy key exchange, it would become a non-event for someone to send or receive an encrypted message. It would have to definitely be widespread enough that, if we also assume pervasive surveillance -- at least on a passive filtering level of some kind -- that to see cyphertext being transmitted back and forth would be common enough that it wouldn't raise alarms or attract attention of any sort. That's the problem, I'm facing, getting the initial seed planted. Let's get real -- assuming surveillance is the new normal, isn't it more likely that cyphertext in the datastream is -- at least as of this day and time -- more likely to attract attention from authorities than say, quality steganography or something like a carefully designed and well executed book code? Maybe the idea of pervasive surveillance and any resulting discomfort will raise interest in easy encryption among the general public, but given the state of the current crypto toolbox, I doubt it. I hope so too. The Tor datastream is easy to recognize amidst the sea of plain text connections. plugwith my plan, most connections are encrypted so those that need to rely on Tor have at least a better chance of hiding it. /plug Besides, with my protocol you really need Tor to protect your cryptographic identities against traffic analysis. Otherwise you're still fair game for the spooks. Guido. [1] my wares are found at http://eccentric-authentication.org/ [2] http://eccentric-authentication.org/blog/2013/06/07/run-it-yourself.html [3] http://dating.wtmnd.nl:10443/aliens (from within the proxied browser session). -- Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech
Re: [liberationtech] Building a encrypted mobile network
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/06/13 17:47, Jonathan Wilkes wrote: Concealing these patterns would require users to send and receive dummy data even when they weren't sending or receiving calls, which would drain their batteries and data allowances. It would be possible to build such a system, but I don't think anyone would use it. I don't think it's out of the realm of possibility that somebody would have a device running orbot with a (non-exit) relay that sits at home, plugged in, running over wifi. Or, some small plug computer with a headset hookup that functions the same. Or on their main machine that just runs all the time. All that's needed then is a mechanism to leave a text message when the other person isn't at home (Torchat, maybe Bitmessage, etc.). Well yes, if you take the mobile out of mobile security, the problem gets easier. ;-) Seriously though, I agree that this could work really well on a Freedombox or similar. Cheers, Michael -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAEBAgAGBQJRuFRfAAoJEBEET9GfxSfMDTMH/35TjGWNl64DrZCvrWRmafO3 qMfufyA6dPPY+0rix7ptMOu4DSyMQ36Q05AdFM0HxB+c2O4wP9nHjSSFq8ba094D /NobvVBrg0Rhn0hNEJ5nMf4yJV1O7LkV+jhDLBJZS+1dYybwJX9LqMQxlBYJnqZG ykLxU0/fFG8XxAi+6fJjsbtO0gRAQqoaq4cByXa9FgtPnleXNaSPD+erGXGoKFIj 4Tbq8dEGOzSGhCK6KGxKn1QKwCxk38G/kxFlg1oZYrZgr3ePdr/5ch5x40by6tzn jv4IqYC6I33+FKc1vcu4eEK+lw89/t9sqt/togHky3j2vhheqV4xbU3uVzF7dv8= =aOCf -END PGP SIGNATURE- -- Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech
Re: [liberationtech] [cryptography] New Anonymity Network for Short Messages
- Forwarded message from James A. Donald jam...@echeque.com - Date: Wed, 12 Jun 2013 15:45:16 +1000 From: James A. Donald jam...@echeque.com To: cryptogra...@randombit.net Subject: Re: [cryptography] [liberationtech] New Anonymity Network for Short Messages User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 Reply-To: jam...@echeque.com On 2013-06-12 1:09 PM, Peter Gutmann wrote: Eugen Leitl eu...@leitl.org either writes or quotes: - Forwarded message from Sean Cassidy sean.a.cass...@gmail.com - - Any specific reason you picked CTR? CTR is widely recommended. Cryptography Engineering specifically recommends it. Who recommends it (apart from CE?). I've seen it warned about in a number of places, and I recommend (strongly) against it in my (still in-progress) book. It's the most dangerous encryption mode since RC4. More specifically, it's RC4 all over again. There's a reason why that was dropped almost everywhere, for example the SDL explicitly bans it, and there's even a Visual Studio tool that scans your code and complains about its use. I don't see this. The problem, as with RC4, is if you re-use your counter. Is there any encryption mode that works if you use it wrong? ___ cryptography mailing list cryptogra...@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 -- Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech
Re: [liberationtech] Internet blackout
@Richard: Alternative infrastructure-type projects like Commotion and other mesh networks can certainly be put in place proactively. In fact, that's a goal of Commotion: encouraging communities to build out their own mesh networks, so residents have more ownership and control over their local infrastructure. When alternative infrastructure is being developed and proactively built out, these communities are more resilient against shutdown of state-controlled networks and can still communicate locally in the case of internet outage. On Wed 12 Jun 2013 06:49:26 AM EDT, Mrs. Y wrote: What about Project Byzantium? http://project-byzantium.org/ The goal of Project Byzantium is to develop a communication system by which users can connect to each other and share information in the absence of convenient access to the Internet. This is done by setting up an ad-hoc wireless mesh network that offers services which replace popular websites often used for this purpose, such as Twitter and IRC. These services and web apps were selected because they are the ones most often used by activists around the world to find one another, exchange information, post media, and organize. They were also selected because they stand the best chance of being easy to use by our intended userbase, which are people using mobile devices like smartphones, MP3 players, and tablet PCs. I interviewed some of the contributors for a podcast on Hacker/maker spaces here: http://packetpushers.net/healthy-paranoia-2-where-no-nerd-has-gone-before/ Michele On 6/11/13 5:44 PM, Richard Brooks wrote: Just finished interacting with people from a number of countries worried about Internet blackouts being used by their governments to help prevent reporting of unpleasant truths, such as vote-rigging. I discussed with them what Telecomics did for Egypt and other Arab countries and what Commotion and mesh-networking may provide. They were enthusiastic about these possibilities, but disappointed when I explained that this was not anything that could be put in place proactively for the moment. This lead me to start thinking about the possibility of deploying something like Fidonet as a tool for getting around Internet blackouts. Has anyone tried something like that? Was wondering if anyone was aware of other approaches for mitigating this type of DoS. -Richard -- Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech -- Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech -- Dan Staples Open Technology Institute https://commotionwireless.net -- Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech
[liberationtech] NSA spying trashes U.S. global role
http://www.cnn.com/2013/06/12/opinion/deibert-nsa-surveillance/ NSA spying trashes U.S. global role By Ronald Deibert , Special to CNN updated 8:32 AM EDT, Wed June 12, 2013 CNN.com Can Americans trust NSA's surveillance? Editor's note: Ronald Deibert is a professor of political science at the University of Toronto, where he is director of the Canada Centre for Global Security Studies and the Citizen Lab at the Munk School of Global Affairs. He is author of Black Code: Inside the Battle for Cyberspace (Signal/McClelland Stewart, 2013). (CNN) -- In 2011, I was on a panel, organized by the security company RSA, with two retired National Security Agency directors, Michael Hayden and Kenneth Minihan. During the course of our debate, I raised concerns, as the only non-American on the panel, that their plans and preferences for having the NSA secure cyberspace for the rest of us were not exactly reassuring. To this, Minihan replied that I should not describe myself as Canadian but rather North American. As jarring as his response was, the fact of the matter is when it comes to communications, he's right. Practically speaking, there is no border separating Canadian from U.S. telecommunications -- though that's not true the other way around. Primarily, this one-way dependence is a product of history and economics. Canadians' communications are inextricably connected to networks south of the border and subject to the laws and practices of the U.S. over which we, as foreigners, have no say or control. For American citizens, the recent NSA scandal has touched off soul-searching discussions about the legality of mass surveillance programs, whether they violate the Fourth and Fifth Amendments of the U.S. Constitution, and whether proper oversight and accountability exist to protect American citizens' rights. Indeed, with respect to the case of PRISM, NSA's secret set of tools used to collect data about overseas Internet communications, some argue the program actually enhances those safeguards for Americans -- because it appears that collection of company data was segregated in such a way to limit the collection to foreign citizens. As reassuring as this may be for Americans, for the rest of us non-Americans who enjoy our Gmail, Google Docs, and Facebook accounts, it's definitely unsettling: We're all fair game. While cyberspace may be global, its infrastructure most definitely is not. For example, a huge proportion of global Internet traffic flows through networks controlled by the United States, simply because eight of 15 global tier 1 telecommunications companies are American -- companies like ATT, CenturyLink, XO Communications and, significantly, Verizon. The social media services that many of us take for granted are also mostly provided by giants headquartered in the United States, like Google, Facebook, Yahoo! and Twitter. All of these companies are subject to U.S. law, including the provisions of the U.S. Patriot Act, no matter where their services are offered or their servers located. Having the world's Internet traffic routed through the U.S. and having those companies under its jurisdiction give U.S. national security agencies an enormous home-field advantage that few other countries enjoy. But there are unintended consequences of the NSA scandal that will undermine U.S. foreign policy interests -- in particular, the Internet Freedom agenda espoused by the U.S. State Department and its allies. The revelations that have emerged will undoubtedly trigger a reaction abroad as policymakers and ordinary users realize the huge disadvantages of their dependence on U.S.-controlled networks in social media, cloud computing, and telecommunications, and of the formidable resources that are deployed by U.S. national security agencies to mine and monitor those networks. For example, in 2012, Norwegian lawmakers debated a ban on the use by public officials of Google's and Microsoft's cloud computing services. Although shelved temporarily, this type of debate will almost certainly be resurrected and spread throughout Europe and other regions as the full scope of U.S.-based foreign directed wiretapping and metadata collection sinks in. Already we can see regional traffic to the United States from Asia, Africa and even Latin America gradually declining, a trend that is almost certainly going to accelerate as those regions ramp up regional network exchange points and local services to minimize dependence on networks under U.S. control. Many of the countries in the Southern Hemisphere are failed or fragile states; many of them are authoritarian or autocratic regimes. No doubt the elites in those regimes will use the excuse of security to adopt more stringent state controls over the Internet in their jurisdictions and support local versions of popular social media companies over which they can exact their own nationalized controls -- a trend that began prior
Re: [liberationtech] New Anonymity Network for Short Messages
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/06/13 17:52, Sean Cassidy wrote:
I have created a simple anonymity network that broadcasts all
messages to participants so that you cannot associate chatters.
Hi Sean,
A few quick questions:
* Do routers subscribe to prefixes, or is it only clients that do so?
If routers subscribe to prefixes, how do you ensure that all routers
subscribed to a given prefix form a connected subgraph?
* A passive observer can pretty quickly tell which prefixes a client
subscribes to by seeing which messages routers send her - her outgoing
messages can be ignored. So can't a global passive observer identify a
group of clients who all subscribe to the same prefix?
struct dinet_packet { uint8_t id[16]; // prefix + random in the
default client uint8_t data[1024]; uint8_t checksum[32]; // SHA-256
checksum of the previous two fields, to avoid flooding the network
with duplicate packets };
* Why is the checksum included in the packet? Each router can
calculate the hash of the previous two fields itself, and discard the
packet if the hash matches a previously seen hash. If the router
trusts the hash included in the packet, it's possible to poison a
router's duplicate detection cache by sending it a packet that has the
same checksum field as another packet but different data.
Cheers,
Michael
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
iQEcBAEBAgAGBQJRuHkBAAoJEBEET9GfxSfMygkH/i7iLj0IhYRqP0Ux6DPjyyK8
zljvmL1cft8uhd3CTOz3sYGzJIiduQuDHG1UEEsNKNMJxETSgQXylQRKPodqPa5Z
a7XLjtyp2Y6Tx/5PC3CU7vtaXvnG+ZLrIsfXsjatQx6sEVoN7dMGPTP3jyaSJl4f
3fp2ZhT0CAFpzXrGnGfOdttoNaKo9KSFTcYIsp/jVdC1YCmaexHpF5j2QjQ8cX83
WEhSZAuhpAUzAwutFpC9H8rpxbcZstucq4TsbjlVsgV0v/UbdYB5Th0UGn6fTISY
z78PK+HU+Co/HXw7VQpd3CZq3Ng03/09na0ZvEbEZqpIwwJrzyZOffNnObd648k=
=SLCZ
-END PGP SIGNATURE-
--
Too many emails? Unsubscribe, change to digest, or change password by emailing
moderator at compa...@stanford.edu or changing your settings at
https://mailman.stanford.edu/mailman/listinfo/liberationtech
Re: [liberationtech] Guardian reporter delayed e-mailing NSA source because crypto is a pain
On 2013-06-12, at 6:20 AM, Eugen Leitl eu...@leitl.org wrote: On Wed, Jun 12, 2013 at 06:15:30AM -0400, Sheila Parks wrote: Why not use her instead of his? Using his in 2013 is, indeed, misogyny List moderator, please control this before it completely goes out of hand. +1 NK People are trying to get work done here, and this is not helping. -- Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech -- Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech
Re: [liberationtech] Guardian reporter delayed e-mailing NSA source because crypto is a pain
On 12 June 2013 11:15, Sheila Parks sheilaruthpa...@comcast.net wrote: Why not use her instead of his? What, in the phrase Glenn Greenwald had to substantially delay his communications ? Surprised you got so many bites. It's not even very high quality trolling :) -- Love regards etc David Miller http://www.deadpansincerity.com 07854 880 883 -- Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech
Re: [liberationtech] the Blackberry and Surveillance?
Michael Ale, I gave numerous interviews back in 2010 when Blackberry started openly co-operating with governments to keep their service online. The concerns raised then, to this day then remain unanswered by the company. Given the company's unwillingness to constructively engage and be open regarding on their practices regarding data sharing has led me to recommend to activists to AVOID their devices and services at all costs. Other far more secure solutions exist, such as the open source Guardian Project. Their secure solutions for Android are excellent and quite respected by digital security practitioners. regards Robert Refs: BlackBerry has reportedly reached an agreement with Saudi Arabia to continue messaging services in the country. It's unclear what data will now be shared. (August 10, 2010) http://www.csmonitor.com/World/Global-News/2010/0810/BlackBerry-caved-to-Saudi-demands-rights-group The Guardian Project: Secure Mobile Apps and Open-Source Code for a Better Tomorrow https://guardianproject.info/ -- R. Guerra Phone/Cell: +1 202-905-2081 Twitter: twitter.com/netfreedom Email: rgue...@privaterra.org On 2013-06-12, at 9:51 AM, ale fernandez wrote: I remember also during the UK riots last year people started using BBM and it was much more effective than other networks also partly due to not being as obvious or closely tracked as facebook posts etc. Ale On Wed, 12 Jun 2013 14:15:33 +0100 Michael Rogers mich...@briarproject.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/06/13 09:14, michael gurstein wrote: I haven`t been watching that closely but in the course of my following the current discussions on surveillance I have yet to see a reference to RIM/Blackberry... Is this because it`s recent loss of market share means it isn`t of particular interest (I would have thought the up to recent user demographics would rather make it of particular interest), because of some features which put it outside of the current surveillance stream, have I missed it in the current discussion, other? Hi Mike, As far as I know, the situation with BlackBerry is as follows. If you're an enterprise customer, you generate your own encryption key for BBM (I don't know whether it's used for email too), and run your own server. RIM claimed in August 2010 that it didn't have access to the encryption keys generated by enterprise customers and couldn't observe the content of their communication. The statement didn't say whether RIM could observe metadata. http://blogs.thenational.ae/business/beep-beep/full-rim-customer-statement-on-blackberry-security-issues If you're a non-enterprise customer, your BBM messages are scrambled with a key that's built into all BlackBerry devices and known to RIM. https://mailman.stanford.edu/pipermail/liberationtech/2013-April/008293.html RIM has come under pressure from several governments to decrypt BBM messages, so I think it's safe to assume that the key used for scrambling non-enterprise BBM messages is widely known by now. For both enterprise and non-enterprise customers, if you use a third-party email provider, that provider will have access to content and metadata regardless of what device you're using. I don't know whether wireless carriers can observe the metadata of BBM messages; they could collect the scrambled messages of non-enterprise customers, for descrambling by anyone who knows the key. Cheers, Michael -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAEBAgAGBQJRuHR1AAoJEBEET9GfxSfMfm4IAJYUc9eD5yZJr4G7kAC5wJSl ZXwrATajTYS+VIxY6yHPe5tQoOMHBXbMF/41No/oua6CoOoU2UU++BHAtGsVarHE koKujVdtn3Tp18Jy6uEru/5qHaNx7+n8FF7lcr72k/yRfgzBKREVH2hge6s2pCYO NcEya2PxKGcwiCk1f3901JwqVoeYxjEVNn2Wjx65lFppX0imn23UALZgnPHQaxX3 t20BYNwz1g1iSiJg2ngxkdOgTeSXelwI0do4h1mEZtFtapfChdjRb9/rAWi1NOwS T8Kos128nDk/0cDuqObONxZD01UjgPIUFxBVVnfjJnKm220r6z7IBpelmrgWi6Y= =9cNa -END PGP SIGNATURE- -- Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech -- Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech -- Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech
Re: [liberationtech] [cryptography] New Anonymity Network for Short Messages
- Forwarded message from Wasa wasabe...@gmail.com - Date: Wed, 12 Jun 2013 15:32:02 +0100 From: Wasa wasabe...@gmail.com To: cryptogra...@randombit.net Subject: Re: [cryptography] [liberationtech] New Anonymity Network for Short Messages User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 On 12/06/13 07:27, Eugen Leitl wrote: Additionally to this, CTR allows bit-level maleability of the cleartext: a bit flipped in a CTR cipherstream translates into a bit flipped in the cleartext. all encryption modes usually provide confidentiality BUT NOT integrity. They have been designed to be CPA secure; not CCA secure. That's why u usually use a MAC along with it... it has nothing to do with CTR... The mode that provides both is CGM In fact, if there are regions of known cleartext (such as zeroes) the adversary can do things like encode the originating IP in the cleartext simply by XORing it into the cipherstream. in CBC if u select the IV incorrectly u also leak info. CBC is only CPA secure IFF the IVs are unpredictable. This property can cause problems if you perform any operations before checking the MAC (like evaluating a weak CRC to decide to forward the message or not). This is also irrelevant. it's got nothing to do with CTR or other modes of encryption; this is all about how u perform authenticated encryption: u should do encrypt-then-mac rather than something else. if u want simple primitives to work with; u can have a look at http://nacl.cr.yp.to/ : implemented by cryptographers. ___ cryptography mailing list cryptogra...@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 -- Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech
Re: [liberationtech] Spy stoppers: meet the companies benefiting from the PRISM privacy scare
Couple of problems in that article: it says google has keys, thats not the problem; google uses EDH ciphersuites by default like the next guy, and while its possible that NSA/PRISM has demanded SSL server keys from google, or from their CA perhaps without googles knowledge, and is actively MITM SSL attacking traffic, real time pre-emptive MITM with server keys or fake certs is slightly more expensive. (I expect they are doing it, but doing it selectively, and most likely with fake certs issued by the correct CA). The main problem with google model is the data is in plaintext on the google servers. (Well probably encrypted on the disk but with a key in RAM). That means google has the data, and as we know FISA authorises the US government to request any and all data as rubber stamped by a closed court. The main alarming thing to me about PRISM is that they are pre-emptively storing everyones data. Then they sift through it afterwards. So to the extent that they may require some kind of suspicion for US targets of analysis (and dont require anything for non-US targets), its not about whether or not to wiretap you, its whether or not to look at the blanket wiretap. Thats a big shift in the balance of power. I notice silent circle offers to generate and manage your keys for you on their servers, that seems like a highly dubious practice, especially given that it is US company. They do have a generate your own keys option. But why would they open themselves up to the FISA orders by even offering to store user keys? Surely thats asking for trouble. Adam On Wed, Jun 12, 2013 at 11:21:49AM -0400, Nadim Kobeissi wrote: The world is still reeling from the leaked details of the NSA's PRISM program, reported to give the government's top spies access to personal user data collected by Google, Apple, Microsoft, and other services. But while the mainstream is fighting over the precise nature of PRISM, the world of cryptography is feeling strangely validated http://www.theverge.com/2013/6/12/4422480/is-prism-good-news-for-cryptographers NK -- Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech -- Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech
Re: [liberationtech] Building a encrypted mobile network
From: Michael Rogers mich...@briarproject.org To: Jonathan Wilkes jancs...@yahoo.com; liberationtech liberationtech@lists.stanford.edu Sent: Wednesday, June 12, 2013 6:58 AM Subject: Re: [liberationtech] Building a encrypted mobile network -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/06/13 17:47, Jonathan Wilkes wrote: Concealing these patterns would require users to send and receive dummy data even when they weren't sending or receiving calls, which would drain their batteries and data allowances. It would be possible to build such a system, but I don't think anyone would use it. I don't think it's out of the realm of possibility that somebody would have a device running orbot with a (non-exit) relay that sits at home, plugged in, running over wifi. Or, some small plug computer with a headset hookup that functions the same. Or on their main machine that just runs all the time. All that's needed then is a mechanism to leave a text message when the other person isn't at home (Torchat, maybe Bitmessage, etc.). Well yes, if you take the mobile out of mobile security, the problem gets easier. ;-) Seriously though, I agree that this could work really well on a Freedombox or similar. It could work well with Tor and a cross-platform gui toolkit that allows it to run on OSX, Windows, GNU/Linux, and (ideally) Android. But yes, if someone developed such an application and got it running on a freedom box[1] I agree that would be extremely useful. Because after all, the freedom box[1] is a widely popular, well-documented, well-supported, and (relatively) inexpensive piece of hardware used not just by computer experts, but also educators, children, entrepreneurs, hobbyists, activists... all kinds of people, all around the world who care about having control over their machines and their data. [1] www.raspberrypi.org -Jonathan -- Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech
Re: [liberationtech] Guardian reporter delayed e-mailing NSA source because crypto is a pain
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/11/2013 09:56 PM, Kate Krauss wrote: This is the beauty of cryptoparties--people can sit next to you and talk you through it. Thanks, Asher Wolf. That is often all it takes. I think it's time for another wave of cryptoparties. - -- The Doctor [412/724/301/703] [ZS] Developer, Project Byzantium: http://project-byzantium.org/ PGP: 0x807B17C1 / 7960 1CDC 85C9 0B63 8D9F DD89 3BD8 FF2B 807B 17C1 WWW: https://drwho.virtadpt.net/ What does it do? How well does it do it? --Sean Kennedy -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlG4lsYACgkQO9j/K4B7F8HsEACg23MSzO17Soz8PPotj5C5fHaW 8pAAn1IS/P6c/mrAWZ31zFCDi4hpZPbO =jJt1 -END PGP SIGNATURE- -- Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech
Re: [liberationtech] New Anonymity Network for Short Messages
On Wed, Jun 12, 2013 at 6:34 AM, Michael Rogers
mich...@briarproject.org wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/06/13 17:52, Sean Cassidy wrote:
I have created a simple anonymity network that broadcasts all
messages to participants so that you cannot associate chatters.
Hi Sean,
A few quick questions:
* Do routers subscribe to prefixes, or is it only clients that do so?
If routers subscribe to prefixes, how do you ensure that all routers
subscribed to a given prefix form a connected subgraph?
ZeroMQ (the library I used to connect routers) allows for filtering
based on messages, but the software as implemented does not support
this. There is actually a bigger issue in ensuring a fully connected
network: the links are not automatically bidirectional. The network
operators must ensure that the graph is connected properly. I did this
to make the routing algorithm (if you can even call it that) simple
and straightforward.
* A passive observer can pretty quickly tell which prefixes a client
subscribes to by seeing which messages routers send her - her outgoing
messages can be ignored. So can't a global passive observer identify a
group of clients who all subscribe to the same prefix?
Prefixes are intended to be small in order to get a large amount of
messages. Clients can (and should) connect to multiple endpoints and
get messages for multiple prefixes, as well as respond on those
prefixes. Perhaps there could be a control channel on the network to
set up random pairs (or groups) of people in order to correspond their
fake prefixes.
struct dinet_packet { uint8_t id[16]; // prefix + random in the
default client uint8_t data[1024]; uint8_t checksum[32]; // SHA-256
checksum of the previous two fields, to avoid flooding the network
with duplicate packets };
* Why is the checksum included in the packet? Each router can
calculate the hash of the previous two fields itself, and discard the
packet if the hash matches a previously seen hash. If the router
trusts the hash included in the packet, it's possible to poison a
router's duplicate detection cache by sending it a packet that has the
same checksum field as another packet but different data.
The router does not trust the hash, but instead recomputes it and
checks it against the given checksum. It was intended to discourage
attacks that just flipped a bit and flooded the network, but this is
sort of a weak protection.
I also had envisioned that clients could monitor their messages from
multiple endpoints (subscribe to themselves) and check that the
checksum is still the same one that was sent. If they never receive
that checksum, either the network is not connected properly, or there
is some destructive tampering going on.
Sean
Cheers,
Michael
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
iQEcBAEBAgAGBQJRuHkBAAoJEBEET9GfxSfMygkH/i7iLj0IhYRqP0Ux6DPjyyK8
zljvmL1cft8uhd3CTOz3sYGzJIiduQuDHG1UEEsNKNMJxETSgQXylQRKPodqPa5Z
a7XLjtyp2Y6Tx/5PC3CU7vtaXvnG+ZLrIsfXsjatQx6sEVoN7dMGPTP3jyaSJl4f
3fp2ZhT0CAFpzXrGnGfOdttoNaKo9KSFTcYIsp/jVdC1YCmaexHpF5j2QjQ8cX83
WEhSZAuhpAUzAwutFpC9H8rpxbcZstucq4TsbjlVsgV0v/UbdYB5Th0UGn6fTISY
z78PK+HU+Co/HXw7VQpd3CZq3Ng03/09na0ZvEbEZqpIwwJrzyZOffNnObd648k=
=SLCZ
-END PGP SIGNATURE-
--
Too many emails? Unsubscribe, change to digest, or change password by
emailing moderator at compa...@stanford.edu or changing your settings at
https://mailman.stanford.edu/mailman/listinfo/liberationtech
--
Too many emails? Unsubscribe, change to digest, or change password by emailing
moderator at compa...@stanford.edu or changing your settings at
https://mailman.stanford.edu/mailman/listinfo/liberationtech
Re: [liberationtech] [ipv6hackers] opportunistic encryption in IPv6
- Forwarded message from Tim tim-secur...@sentinelchicken.org - Date: Wed, 12 Jun 2013 09:34:11 -0700 From: Tim tim-secur...@sentinelchicken.org To: IPv6 Hackers Mailing List ipv6hack...@lists.si6networks.com Subject: Re: [ipv6hackers] opportunistic encryption in IPv6 User-Agent: Mutt/1.5.20 (2009-06-14) Reply-To: IPv6 Hackers Mailing List ipv6hack...@lists.si6networks.com Hi guys, Long time lurker, seldom poster. I've read through this whole thread to date and just want to make a couple of comments. I'm reasonably sure that there is a potentially huge demand for passive attack protection for end users and enterprises. If this could be package-ready for Linux or FreeBSD then eventual deployment numbers could be considerable. Here, I just don't understand the logic. To me, encrypting without authenticating buys you absolutely nothing, except to burn CPU cycles and contribute to global warming. In the *vast* majority of networking technology we use, modifying data in transit is just as easy as passively reading data in transit, within a constant factor. (That is, in a big-O sense, these are the same difficulty.) S many different attempts at creating encryption protocols have utterly failed, and in most cases, it is because the designers have put the cart before the horse. They've started with the easy encryption problem rather than addressing the hard authentication problem. Indeed, you may be able to convince the world at some point to adopt opportunisitic encryption without authentication, since so many people don't understand that it doesn't buy you anything. But then they'll be shocked when the first guy writes and releases a MitM tool for it. Now, does this mean authentication is a black-and-white matter? No. Currently the whole world relies on SSL/TLS's PKI, which has been shown to be quite weak, especially in the face of government meddling. The ways in which SSL/TLS is used adds more weaknesses. But at some level, we get by. It is ok, to have weak authentication so long as you have a way to gradually build the trust of an entity's identity from that. As an aside: the idea embodied in CGAs is a powerful one: By making my address my key (signature), I'm implicitly binding my key to my protocol. However, CGAs address this problem at network layer, not at the human layer. So all it takes to bypass it is to MitM the protocol that hands out addresses for hosts. However, as a building block, it could be useful. Also, for those who aren't familiar with it, I strongly urge you to read up on Identity Based Encryption, where any string can be a public key, within a predefined authentication realm. Regarding the earlier comparison of different PKIs, I think we need something that merges some of the concepts of webs of trust with what we're using right now in the TLS PKI. Let me throw out an outline of what I think would work better and has a chance at adoption: - Certificates can be signed by multiple CAs. The number and quality of signatures determines the level of trust of a certificate. - The act of communicating with a node causes their key (or CA's key) to be signed and that signature to be published automatically. The logic is, if you trusted a node's identity once, then you should share the knowledge of that trust. This publishing process needs to be anonymized somehow. There needs to be incentives for publishing (think bitcoin). - Not everyone is a CA. Perhaps each major organization would act as a CA and sign certificates of other CAs. Users would leverage their org's trust network and not need to deal with signing at and endpoint level, though their own org would be aware of transactions with new external entities and autosign as necessary. Many of these ideas have obviously been proposed before and my outline is very generic, but meant as a starting point for discussion. Also, I realize that I've veered away from IPv6 specifically, but I think any discussion of authentication needs to start with people, not protocols, and then trickle down to the protocol level, not the other way around. Cheers, tim ___ Ipv6hackers mailing list ipv6hack...@lists.si6networks.com http://lists.si6networks.com/listinfo/ipv6hackers - 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 -- Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech
Re: [liberationtech] Guardian reporter delayed e-mailing NSA source because crypto is a pain
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 2013.06.12 11.54, micah wrote: I'm constantly hearing from people who complain about the UI in things like gnupg. I feel your pain, I do not want to argue that you are wrong. However, I do want to argue that complaining doesn't help to solve the problem. I've asked every single person who has complained about this problem to me recently, have you filed a bug about your issues? and everyone's response is: no. I've done this, and guess what? It works! I filed bugs and had discussions on the gnupg mailing list that have made your experience with that tool a little bit better. There are many ways that I think it can be improved still, don't get me wrong, but the gnupg developers are reasonable people who want to make the software better, and probably have been hearing these complaints for years and years and would welcome a way to make people stop complaining. It seems there are a lot of people out there who have a clear idea of what is good and what is bad UI and are pretty vocal about when something is bad. How about turning that into clear bugs that describe better workflow and UI? You dont have to be a crypto nerd, or a C programmer to make this stuff better and easier to use. Is there any point in filing a bug that says Please have a professional designer re-work all use flows in this system from scratch? (No.) Is there any point in filing a bug that says Please remove features X, Y, Z, Q, R, N, and M because they're too confusing for novice users? (No, especially when X is the entire web of trust.) Filing bugs isn't enough -- it's an entire design effort. Individuals may see a thing and think hey, this could be changed, but what's needed is a top-to-bottom redesign, and that does not translate into a simple set of clear bugs. I don't believe that the GPG designers have the resources available to do this design effort as it stands, and it's not just them, it's the entire ecosystem that needs to be involved and work together. We'd love to see this fixed. If it was this easy, it would have been done years ago. E. - -- Ideas are my favorite toys. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) iF4EAREIAAYFAlG4nLkACgkQQwkE2RkM0wpFNAD9Ez3mXSJRDrU5ViXz7+k1xbdd iObK9CUbmIpPTmL+BoUA/315DpJFjW4FbO5L2yyTAix7X2QuV7UTzYaX4/XwZHF6 =nDoe -END PGP SIGNATURE- -- Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech
[liberationtech] Blogpost: learning lessons from NSA's PRISM (or: crypto decentralization vs. bulk spying)
Dear all, I spent some time writing a blogpost aimed at not-so-aware people who may have heard about PRISM but lack the background knowledge about massive surveillance and as such could make incorrect decisions if trying to protect themselves. https://words.ceops.eu/posts/Learning%20the%20lesson%20from%20NSA%27s%20PRISM:%20don%27t%20do%20it%20wrong/ I wrote it with the hope that it'll be useful and improve the understanding of these people. Best and datalove, KheOps -- Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech
Re: [liberationtech] [cryptography] [ipv6hackers] opportunistic encryption in IPv6
- Forwarded message from Will Yager will.ya...@gmail.com - Date: Wed, 12 Jun 2013 11:08:27 -0500 From: Will Yager will.ya...@gmail.com To: cryptogra...@randombit.net Subject: Re: [cryptography] [ipv6hackers] opportunistic encryption in IPv6 X-Mailer: iPhone Mail (10B146) The process of randomly generating and calculating a public key for every brute-force attempt will slow the process considerably. However, for further key stretching, perhaps many iterations of SHA-* et al. is not the best option. Since web servers may be processing thousands of new connections per second, thousands of iterations of SHA and co. per connection may be prohibitively time-intensive for servers to implement. At the same time, attackers with GPUs/FPGAs/ASICs will have an advantage of several orders of magnitude. Perhaps in this case, it would be wise to leverage a universally slow algorithm like Scrypt. It's not more difficult to implement than SHA et al. but it's slower to brute-force with dedicated crypto hardware. On Jun 12, 2013, at 5:21, Eugen Leitl eu...@leitl.org wrote: - Forwarded message from Jim Small jim.sm...@cdw.com - Date: Wed, 12 Jun 2013 03:31:10 + From: Jim Small jim.sm...@cdw.com To: IPv6 Hackers Mailing List ipv6hack...@lists.si6networks.com Subject: Re: [ipv6hackers] opportunistic encryption in IPv6 Reply-To: IPv6 Hackers Mailing List ipv6hack...@lists.si6networks.com Here's an interesting question more relevant to the list and the paper though - are IPv6 CGAs useful? It seems like SeND is dead. But does anyone on the list think that CGAs could provide a useful competitive advantage for IPv6 over IPv4? Are these a useful building block? I believe CGAs solves PKI problem entirely. If using CGAs one does not need any PKI or CA certificate at all. True as long as you don't need authentication. But I have to concede, the whole point of OE is just to encrypt the traffic. Each node having CGA can give self signed certificate. The certificate is used only to extract public key (PK), modifier, collision counter and any extension fields. Extracted information can be used to verify that host address is valid CGA with the given public key. Next step is symmetric key negotiation. If during key negotiation messages are encrypted with the specified public key then only node having the corresponding private key can decrypt key negotiation messages. This step ensures that MITM is not possible if you are using CGA generated not from your own public/private key pair. If you use your own public/private keys then you no longer can easily choose your address. If using CGA+IPSEC then IKE daemon can do the key negotiation part when given authenticated public key. In SEND PKI is used only to protect from rogue routers. Only certificates signed by the CA should be able to send router advertisements. TLDR: For address authentication (protection against MITM) when using CGA no PKI is needed. Per RFC 3972, CGAs are not certified. I read the RFC as assuming a strong hash and secure private key, once someone uses a CGA someone else can't hijack/impersonate that address. So they are great for unauthenticated encryption. CGAs is holy grail for opportunistic encryption. Node can immediately start using opportunistic encryption by generating self signed certificate and CGA. One thing I wonder about is a 64 bit hash is pretty small - I wonder if that is sufficiently complex to provide security for the coming decade+? When generating CGA you can choose security level which allows to slow down brute force attacks (search for modifiers which would generate specific CGA address). Security level is encoded in the first three bits of the address. Because of that CGAs with lower security does not overlap with stronger CGAs. True, but I wonder how well this fairs against modern massive parallel GPU crackers. SHA-1 is a weak hash. Would be nice to see an update using SHA-2/SHA-3 and to mandate longer key lengths - say = 2048 bits. Otherwise doesn't it seem like we're going down the WEP path again? Still - it's a great point, CGAs do seem well suited for OE if you can live with the limitations. Is there anything that currently supports this? I'm wondering how much IPv6 market value this has... --Jim ___ Ipv6hackers mailing list ipv6hack...@lists.si6networks.com http://lists.si6networks.com/listinfo/ipv6hackers - 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 ___ cryptography mailing list cryptogra...@randombit.net
[liberationtech] Opt out of Prism
Dear friends, i would like to share with you this project and see your comments. http://prism-break.org/ best, -- Andrea Stroppa http://huffingtonpost.com/andrea-stroppa @andst7 -- Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech
Re: [liberationtech] New Anonymity Network for Short Messages
the ideal would be to hit a high enough rate that it makes real-time analysis of content (by a human) impossible. By the time the service hit that rate of chats, it will be nigh-unusable by people. Every client could broadcast a message on a timer. Sometimes the message would be wheat and sometimes chaff. Then the downsides would be: 1) Additional latency between composing the message and the next timer pulse. In terms of UX, slower sends. 2) A bigger buffer, flushing more often. Problem #2 could be ameliorated with something like sharding. If there were S shards and M messages total, a peer would buffer M/S messages. On Tue, Jun 11, 2013 at 11:42 AM, Griffin Boyce griffinbo...@gmail.comwrote: Sean Cassidy sean.a.cass...@gmail.com wrote: First is that if the load on the network is high enough, conversations can hide in the noise. This is helped by dummy message generation either by clients or servers (preferably clients to protect against attackers that can monitor every node). Unless I'm missing something (entirely possible): From your standpoint, the ideal would be to hit a high enough rate that it makes real-time analysis of content (by a human) impossible. By the time the service hit that rate of chats, it will be nigh-unusable by people. This is more or less why chat channels (eg, IRC) were created in the first place. And that doesn't preclude outside observers from storing and correlating the chats. ~Griffin -- Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech -- Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech
Re: [liberationtech] [cryptography] [ipv6hackers] opportunistic encryption in IPv6
On Wed, Jun 12, 2013 at 05:59:38PM +0200, Eugen Leitl wrote: Here, I just don't understand the logic. To me, encrypting without authenticating buys you absolutely nothing, except to burn CPU cycles and contribute to global warming. In the *vast* majority of networking technology we use, modifying data in transit is just as easy as passively reading data in transit, within a constant factor. (That is, in a big-O sense, these are the same difficulty.) So what? Being able to detect if you are being attacked, even if most people don't bother, is a huge step forward over having no way of knowing at all. -- 'peter'[:-1]@petertodd.org 002c90d9b4f79320cf4b85fef8165be49be8ebcc29be25d353db -- Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech
Re: [liberationtech] Opt out of Prism
On 6/12/13 10:21 AM, John Adams wrote: [...] This is one of the reasons why the EFF does not recommend tools. The issues associated with each tool are myriad and vast. [...] Huh? The EFF Surveillance Self Defense article, while out-of-date, does recommend tools. https://ssd.eff.org/tech -- Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech
Re: [liberationtech] Opt out of Prism
There are a few great places to look at your options for breaking out of tracking situations: Fix your tracking situation (to some extent): http://fixtracking.com/ Get recommendations at: http://prism-break.org/ Get more in-depth information and recommendations: https://ssd.eff.org/tech ~Griffin -- Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech
Re: [liberationtech] Opt out of Prism
On 12-06-13 19:21, John Adams wrote: I like that you're promoting free and open tools, but your title is misleading. You offer people false hope here. By listing the tools and not listing what level of security they offer, people will assume they can just switch and be protected. This is one of the reasons why the EFF does not recommend tools. The issues associated with each tool are myriad and vast. What's sad is that the media picked up on this, amplifying the false hope you offer. A+ for effort, though. Although I can agree that many of these tools do not offer (significant) protection against unwanted data gathering. It's good that such a list comes to the attention of the people who are worried about their privacy. Even with false hope, a society without hope is doomed... I hope some people will take time to switch to some tools and spread that knowledge further. Guido. -- Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech
Re: [liberationtech] Opt out of Prism
Dear friends about John Adams, i just copied the title of the website. No more, no less. 2013/6/12 Guido Witmond gu...@witmond.nl On 12-06-13 19:21, John Adams wrote: I like that you're promoting free and open tools, but your title is misleading. You offer people false hope here. By listing the tools and not listing what level of security they offer, people will assume they can just switch and be protected. This is one of the reasons why the EFF does not recommend tools. The issues associated with each tool are myriad and vast. What's sad is that the media picked up on this, amplifying the false hope you offer. A+ for effort, though. Although I can agree that many of these tools do not offer (significant) protection against unwanted data gathering. It's good that such a list comes to the attention of the people who are worried about their privacy. Even with false hope, a society without hope is doomed... I hope some people will take time to switch to some tools and spread that knowledge further. Guido. -- Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/**mailman/listinfo/**liberationtechhttps://mailman.stanford.edu/mailman/listinfo/liberationtech -- Andrea Stroppa http://huffingtonpost.com/andrea-stroppa @andst7 -- Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech
Re: [liberationtech] Opt out of Prism
I see many emails from journalists here about this project. I'm not the author, i'm just a visitor like you. the author's email is: p...@nylira.com (you can find on the footer) thank you! 2013/6/12 Andrea St and...@gmail.com: Dear friends about John Adams, i just copied the title of the website. No more, no less. 2013/6/12 Guido Witmond gu...@witmond.nl On 12-06-13 19:21, John Adams wrote: I like that you're promoting free and open tools, but your title is misleading. You offer people false hope here. By listing the tools and not listing what level of security they offer, people will assume they can just switch and be protected. This is one of the reasons why the EFF does not recommend tools. The issues associated with each tool are myriad and vast. What's sad is that the media picked up on this, amplifying the false hope you offer. A+ for effort, though. Although I can agree that many of these tools do not offer (significant) protection against unwanted data gathering. It's good that such a list comes to the attention of the people who are worried about their privacy. Even with false hope, a society without hope is doomed... I hope some people will take time to switch to some tools and spread that knowledge further. Guido. -- Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech -- Andrea Stroppa http://huffingtonpost.com/andrea-stroppa @andst7 -- Andrea Stroppa http://huffingtonpost.com/andrea-stroppa @andst7 -- Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech
[liberationtech] Dual Citizens and Information Collection
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Obviously we don't know much about NSA/CIA spying on citizens and non-citizens but my question is this: I am a dual citizen of the US and Canada, many of the tools I use I identify as a Canadian. I am the leader of a Canadian political party, and in general I am very much a dual citizen (as opposed to having dual citizenship). I was wondering if you guys had any ideas on how to potentially leverage that to perhaps sue the CIA in an effort to ensure they are not collecting any data on Travis McCrea the Canadian who is Travis McCrea the American. Is this possible? Do I have anything I can do? I just want to help and figure this might be an avenue to take. -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBCgAGBQJRuLwxAAoJEES9cOv0A0l0IYAH+gOCLuwkkcz7Ja3qPKHP98bk cBfx9mJ3L8j9MrcxKWPgvE20rJxeT86MYICLrRNV5YG2w7xr+Qvya5X7U/FVfgqy w6m9NaPXmHowK5NYHXJ1k//j1KrjIJt11aPwIgUkl5+LD25gspt/PuAzHspc0b1Z QvEWcG6eDHZfy4BO8T8rk9cEF+a2lnXh5156X/PUQKMibASukQIvlJl2+uUifhwZ PkrrniWcgABKkKbhsYdyHDh2AvlxSEtuJAAtVz0pf8+yHtKedTCh4pY2CSMTVZng fFrrX1MKSiL9Tcba0hJ5+IqysTdu6BciEEzadV1JYlvDfp5TWxHff4B/zVhu64w= =9Urh -END PGP SIGNATURE- -- Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech
Re: [liberationtech] Opt out of Prism
My bad, I thought you were the author of the page. In any event, I hadn't seen the EFF SSD page and had been cautioned by EFF staffers about recommending tools. Their approach is vastly better (albeit more verbose) than just raw recommendations of products. They go into full explanations of what the tools can and cannot provide. -j On Wed, Jun 12, 2013 at 11:13 AM, Andrea St and...@gmail.com wrote: Dear friends about John Adams, i just copied the title of the website. No more, no less. 2013/6/12 Guido Witmond gu...@witmond.nl On 12-06-13 19:21, John Adams wrote: I like that you're promoting free and open tools, but your title is misleading. You offer people false hope here. By listing the tools and not listing what level of security they offer, people will assume they can just switch and be protected. This is one of the reasons why the EFF does not recommend tools. The issues associated with each tool are myriad and vast. What's sad is that the media picked up on this, amplifying the false hope you offer. A+ for effort, though. Although I can agree that many of these tools do not offer (significant) protection against unwanted data gathering. It's good that such a list comes to the attention of the people who are worried about their privacy. Even with false hope, a society without hope is doomed... I hope some people will take time to switch to some tools and spread that knowledge further. Guido. -- Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/**mailman/listinfo/**liberationtechhttps://mailman.stanford.edu/mailman/listinfo/liberationtech -- Andrea Stroppa http://huffingtonpost.com/andrea-stroppa @andst7 -- Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech -- Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech
Re: [liberationtech] nettime dark days
- Forwarded message from Eric Beck ersatz...@gmail.com - Date: Wed, 12 Jun 2013 10:41:48 -0500 From: Eric Beck ersatz...@gmail.com To: nettim...@kein.org Subject: Re: nettime dark days On Wednesday, June 12, 2013, Keith Hart wrote: European governments are challenging the Obama administration, If this is your bulwark against the dark days, I'd consider embracing despair. The European states might talk a good game--like they did before the second Iraq war--but both the demands of conjunctural geopolitics and the dynamics of statecraft would seem to dictate that they are much more likely to go along to get along, after registering their pro forma dissents. This paragraph from a Der Spiegel article on US data retrieval and storage indicates why: The NSA is a useful partner for German authorities. The director of the NSA, four-star General Keith Alexander, regularly receives delegations from Germany at his headquarters at Fort Meade. These meetings are generally constructive, in part because the pecking order is clear: The NSA nearly always knows much more, while the Germans act as assistants. the response within the US will be heavier. So far, not really. The polls released indicate that USers are mostly okay with what the NSA has done, or what's been revealed of it so far. More relevantly, the impulse among those who were potentially part of the heavy response has been to protect the Democratic president and slander Snowden/Greenwald. That in itself is bad enough, but that it's been carried out in ways that hew closely to ideas about criminal subjectivity (if you have nothing to hide, you don't need to worry) and the sanctity of the nation (Snowden is a traitor!) suggests that the circle drawn around the sovereign is pretty tight and fierce. Is it better not to know that to know the extent of the surveillance state? Of course, with the provisos that the leaks don't reveal the extent and that knowledge is not the same as escape. It's also possible that such knowledge has a chilling effect. The Panopticon set up the technology for complete surveillance, but part of its rationale was that prisoners never really knew when they were being watched, creating a sort of self-management and -regulation among them. Once in awhile, it's effective for the spied-upon to be reminded they are being spied upon. None of this is meant to predict the future (though I feel sure the first two points I made here will continue to be true), but to question landing on the side of either optimism or despair. It gives them too much credit to declare ahead of time that change is dependent on crisis *or* plenitude. # 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: nett...@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 -- Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech
Re: [liberationtech] Dual Citizens and Information Collection
On 12 June 2013 14:21, Travis McCrea m...@travismccrea.com wrote: I was wondering if you guys had any ideas on how to potentially leverage that to perhaps sue the CIA in an effort to ensure they are not collecting any data on Travis McCrea the Canadian who is Travis McCrea the American. Is this possible? Do I have anything I can do? I just want to help and figure this might be an avenue to take. If you seriously are willing to finance a lawsuit I would suggest you speak with the ACLU or the Canadian equivalent. Any speculation we give will probably be wildly inaccurate. =) -tom -- Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech
Re: [liberationtech] Ostel: encrypted phone calls
We've updated the app and the website a bunch this week. We hope that it's even more useful and functional now. Please go to ostel.co and start using our tool for encrypted phone calls. We'd love to hear feedback. Thanks! --* @mbelinsky https://twitter.com/mbelinsky | markbelinsky.comhttps://markbelinsky.com| phone: +1-347-466-9327 | skype: markontheline * On Thu, Jun 6, 2013 at 5:04 AM, Raven Jiang CX j...@stanford.edu wrote: The article mentioned that the order for the dragnet came from the FISA court. Doesn't electronic surveillance of agents that do not belong to foreign entities exceed the legal jurisdiction of the FISA court? On 6 June 2013 00:02, Michael Carbone mich...@accessnow.org wrote: Now is a great time to push OStel further out, as clear evidence that the NSA is scooping up all noncontent cellphone data (including domestic-domestic) is hitting the news: http://www.guardian.co.uk/world/2013/jun/06/nsa-phone-records-verizon-court-order Michael On Jun 5, 2013 6:03 PM, Nathan of Guardian nat...@guardianproject.info wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/05/2013 02:25 PM, Mark Belinsky wrote: When we initially developed ostel.me it used freeswitch but we've moved away from it to allow for better federation. Ostel.co is a new implementation of the open secure telephony network (ostn) standard If you want to track the open-source project behind OStel, you can find on the project tracker[0] and post questions on the guardian-dev list [1]. As Mark mentioned, this is our second go around at creating an Open Secure/Source/Standards Telephony Network [2] service, this time based on the popular+powerful Kamalio [3] SIP server. Soon, we will have all the information posted on how to run your own instance too. We previously documented how to do this with our v1 Freeswitch-based cookbook [4]. After all, we still believe in things like standards, federation and the ability to run your own servers, because, well, that is what the Internet is made of. +n [0] OStel Project Tracker: https://dev.guardianproject.info/projects/ostel [1] Guardian-dev Mailing List: https://lists.mayfirst.org/mailman/admin/guardian-dev [2] OSTN Project Overview: https://guardianproject.info/wiki/OSTN [3] Kamailio: http://www.kamailio.org/w/ [4] DEPRECATED: Run your own OSTN node: https://guardianproject.info/wiki/OSTN_cookbook -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRr7WdAAoJEKgBGD5ps3qpOswP/RuA6id38QvnUUVxiSpncUxc uwmPo/DtytirKakI+ZZSeAcN0NFTaExIemye/+QLZUBhGr03O3dwG3KlRYt4ztI3 yHk8knWK6CUH3vZqluZdB4dX9EWPET0rh+Makf8Qxhzv7F9zIVMk+2CgoPSex078 MEwXPY7+d7rq3XwwAQHLpjMXxU3J9FXdljRiULr9XyEcTwH7i7T2JzHDx3B9BHE2 5Mqrsaylm9RkkKUuIBLwrOpp8vxGT3Y5qwHQSo0LWIwMi8zm60ScG61eB7xpVmS6 wXrqwb2Gs/ay66yexgJ9A05GYiodE3KDvIUB3Aa9Eu34zzQ0vyS9EGJhKWpEyaqm YsLy9MezpmC3hkVLFHOawoN9BjRivX4KTnyvdPjDV621HoJO5r8qmnbrZKha7jio tNiYLq+bwFabU2DSP4f1k67S2CG0t5IktuLAg2Ckfrg0g3NxfnDT4Q2CANr6h7SC Pryx5+BAebpu4J/Pv1iiBTx7uefrwXYltx2jxF6YoAHnnu6jiJjzvIfAwrvuXNq9 bnsO8TvYFzzPA+i2237WiUvSvOQxjQQQEM4OROJ75VZ9V41ONVy2ndZq8AJmH9dL RhaKJNfr5sXdY3yOSWr3ohUH58hDWR0glaUyt8n6Z47uJVWHJr/whnyAD7YCTvf2 zyJLnld3E5C+/aajioma =NqX3 -END PGP SIGNATURE- -- Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech -- Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech -- Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech -- Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech
Re: [liberationtech] Guardian reporter delayed e-mailing NSA source because crypto is a pain
From: micah mi...@riseup.net To: Andy Isaacson a...@hexapodia.org; liberationtech liberationtech@lists.stanford.edu Sent: Wednesday, June 12, 2013 11:54 AM Subject: Re: [liberationtech] Guardian reporter delayed e-mailing NSA source because crypto is a pain Andy Isaacson a...@hexapodia.org writes: I use gnupg daily. So do I, and you might too, and do not realize it! If you use Debian, a Debian derivative (like Ubuntu), you use this stuff all the time, and don't even have to think about it. I do not consider the tools easy to use at all ... When you talk about how hard this stuff is, and how unusable it is, don't forget that there are cases where it is so easy and usable that you are not even aware of it. Don't forget, however, that both users and devs of Debian can essentially ignore the finer details of GPG because of the way the Debian community itself operates. Because freely available, freely auditable software is the product around which the community is based, and because the Debian community itself is made up of an unusually (uniquely?) high proportion of software mavens, GPG web of trust can be leveraged to lower the cost of maintaining a decentralized repository for the code/binaries. If shenanigans happen, the result (if any) will be evident in changed code/binary, which has a history and can be changed back; moreover, since the entire community is highly educated, even the laziest dev will quickly get up to speed if his/her key turns out to be comprimised. If we're going to refer to Debian in this context, it should be as shining example of what can be achieved when there's a critical mass of community members who know what their strengths are and use them to make a system better than it was when they found it, and give those improvements freely to everyone. If you remove free software as the core goal and replace it with Bitcoin OTC, community credits or even free software equivalent of Facebook's Like button, then you must reassess every single benefit that web of trust has in Debian. (E.g., there's no risk of credit default swaps with free software.) -Jonathan -- Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech
[liberationtech] The government is no longer the only party to win a matter in the FISA Court
Now EFF has too. https://www.eff.org/document/fisc-opinion-and-order-granting-effs-motion -- James S. Tyre Law Offices of James S. Tyre 10736 Jefferson Blvd., #512 Culver City, CA 90230-4969 310-839-4114/310-839-4602(fax) jst...@jstyre.com Policy Fellow, Electronic Frontier Foundation https://www.eff.org -- Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech
Re: [liberationtech] Guardian reporter delayed e-mailing NSA source because crypto is a pain
+1 Micah +1 Jillian Anne and Paul. On Jun 12, 2013 7:24 PM, micah mi...@riseup.net wrote: Eleanor Saitta e...@dymaxion.org writes: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 2013.06.12 11.54, micah wrote: I'm constantly hearing from people who complain about the UI in things like gnupg. I feel your pain, I do not want to argue that you are wrong. However, I do want to argue that complaining doesn't help to solve the problem. I've asked every single person who has complained about this problem to me recently, have you filed a bug about your issues? and everyone's response is: no. I've done this, and guess what? It works! I filed bugs and had discussions on the gnupg mailing list that have made your experience with that tool a little bit better. There are many ways that I think it can be improved still, don't get me wrong, but the gnupg developers are reasonable people who want to make the software better, and probably have been hearing these complaints for years and years and would welcome a way to make people stop complaining. It seems there are a lot of people out there who have a clear idea of what is good and what is bad UI and are pretty vocal about when something is bad. How about turning that into clear bugs that describe better workflow and UI? You dont have to be a crypto nerd, or a C programmer to make this stuff better and easier to use. Is there any point in filing a bug that says Please have a professional designer re-work all use flows in this system from scratch? (No.) I agree, there is not much point in that. Is there any point in filing a bug that says Please remove features X, Y, Z, Q, R, N, and M because they're too confusing for novice users? (No, especially when X is the entire web of trust.) I somewhat disagree with you on this point. There is a point to filing a bug that says, Please remove the choice of RSA/DSA/Elgamal from the gpg --gen-key process and just automatically use the default unless the user has passed --advanced. It is confusing for a user who is just learning to use the tool to have to make this choice. Filing bugs isn't enough -- it's an entire design effort. I do not think that it is one or the other. Don't throw out the bugs or usability enhancements because you think that the whole thing needs to be redesigned. Individuals may see a thing and think hey, this could be changed, but what's needed is a top-to-bottom redesign, and that does not translate into a simple set of clear bugs. I don't believe that the GPG designers have the resources available to do this design effort as it stands, and it's not just them, it's the entire ecosystem that needs to be involved and work together. I disagree. I've been working with people who have been doing this sort of iterative changes with the software for years and things have gotten better. It is actually not that hard to make significant usability changes without needing to make top-to-bottom changes. For example, here is a bug I filed which coalesces my experiences doing gnupg trainings with different activists and the stumbling blocks that we ran into: https://bugs.g10code.com/gnupg/issue1506?@ok_message=msg%204634%20created%0Aissue%201506%20created@template=item We'd love to see this fixed. If it was this easy, it would have been done years ago. You would be surprised the changes that you can get if you ask for them and describe clearly why they are needed. It helps a lot if you can also clearly describe a better alternative. If you know how to code and have time, then providing a patch will go even further. Although patches are always welcome, they are not required. For a really long time, smart cryptographers have been writing this software, their heads are focused on doing the correct technical thing and that doesn't always translate into an easy experience. They have been doing this so long that they cannot see how this could be any different. It is up to us who aren't so deeply stewed in hashing algorithms and trust metrics, we who work with people who provide us the feedback who can synthesize it and bring that back to those people in who know the code so that they can make it more usable. If we do not do that, it will not happen, ever. No matter how much we complain in places where they will never hear us. My experience has been that software gets better when I point out the problems to the appropriate place that the developers have asked for those things to be put. Sometimes that takes several years, sometimes I get lucky and the change happens in a weekend. It very rarely gets better on its own. You may think that the whole crypto world needs to be thrown out and we need to start again, and you see that as an intractably impossible problem. I see things differently because I've seen annoying things iteratively become usable over time, and I've seen usable
[liberationtech] Use of gender-neutral terms when speaking and writing
Dear list, FYI, the standard practice at Stanford (and many other universities and Fortune 500 corporations) is to use gender-neutral terms when speaking or writing. Doing otherwise is considered disrespectful. Of course, everyone has a right to free speech. But, if someone is disrespectful, the reader also has a right to get angry, especially when the writer's comments are deemed insensitive to 50%+ of the population. Fortunately, many on the list have already made this point, so let's move on. Thanks, Yosem, one of the list moderators On Wed, Jun 12, 2013 at 1:48 PM, Brian Conley bri...@smallworldnews.tvwrote: +1 Micah +1 Jillian Anne and Paul. On Jun 12, 2013 7:24 PM, micah mi...@riseup.net wrote: Eleanor Saitta e...@dymaxion.org writes: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 2013.06.12 11.54, micah wrote: I'm constantly hearing from people who complain about the UI in things like gnupg. I feel your pain, I do not want to argue that you are wrong. However, I do want to argue that complaining doesn't help to solve the problem. I've asked every single person who has complained about this problem to me recently, have you filed a bug about your issues? and everyone's response is: no. I've done this, and guess what? It works! I filed bugs and had discussions on the gnupg mailing list that have made your experience with that tool a little bit better. There are many ways that I think it can be improved still, don't get me wrong, but the gnupg developers are reasonable people who want to make the software better, and probably have been hearing these complaints for years and years and would welcome a way to make people stop complaining. It seems there are a lot of people out there who have a clear idea of what is good and what is bad UI and are pretty vocal about when something is bad. How about turning that into clear bugs that describe better workflow and UI? You dont have to be a crypto nerd, or a C programmer to make this stuff better and easier to use. Is there any point in filing a bug that says Please have a professional designer re-work all use flows in this system from scratch? (No.) I agree, there is not much point in that. Is there any point in filing a bug that says Please remove features X, Y, Z, Q, R, N, and M because they're too confusing for novice users? (No, especially when X is the entire web of trust.) I somewhat disagree with you on this point. There is a point to filing a bug that says, Please remove the choice of RSA/DSA/Elgamal from the gpg --gen-key process and just automatically use the default unless the user has passed --advanced. It is confusing for a user who is just learning to use the tool to have to make this choice. Filing bugs isn't enough -- it's an entire design effort. I do not think that it is one or the other. Don't throw out the bugs or usability enhancements because you think that the whole thing needs to be redesigned. Individuals may see a thing and think hey, this could be changed, but what's needed is a top-to-bottom redesign, and that does not translate into a simple set of clear bugs. I don't believe that the GPG designers have the resources available to do this design effort as it stands, and it's not just them, it's the entire ecosystem that needs to be involved and work together. I disagree. I've been working with people who have been doing this sort of iterative changes with the software for years and things have gotten better. It is actually not that hard to make significant usability changes without needing to make top-to-bottom changes. For example, here is a bug I filed which coalesces my experiences doing gnupg trainings with different activists and the stumbling blocks that we ran into: https://bugs.g10code.com/gnupg/issue1506?@ok_message=msg%204634%20created%0Aissue%201506%20created@template=item We'd love to see this fixed. If it was this easy, it would have been done years ago. You would be surprised the changes that you can get if you ask for them and describe clearly why they are needed. It helps a lot if you can also clearly describe a better alternative. If you know how to code and have time, then providing a patch will go even further. Although patches are always welcome, they are not required. For a really long time, smart cryptographers have been writing this software, their heads are focused on doing the correct technical thing and that doesn't always translate into an easy experience. They have been doing this so long that they cannot see how this could be any different. It is up to us who aren't so deeply stewed in hashing algorithms and trust metrics, we who work with people who provide us the feedback who can synthesize it and bring that back to those people in who know the code so that they can make it more usable. If we do not do that, it will not happen, ever. No matter how
[liberationtech] FW: The government is no longer the only party to win a matter in the FISA Court
Meant to post this to the whole list, sorry. -- James S. Tyre Law Offices of James S. Tyre 10736 Jefferson Blvd., #512 Culver City, CA 90230-4969 310-839-4114/310-839-4602(fax) jst...@jstyre.com Policy Fellow, Electronic Frontier Foundation https://www.eff.org -Original Message- From: James S. Tyre [mailto:jst...@eff.org] Sent: Wednesday, June 12, 2013 2:23 PM To: 'Bernard Tyers - ei8fdb' Subject: RE: [liberationtech] The government is no longer the only party to win a matter in the FISA Court Hi Bernard, whose surname is almost confusingly similar with mine. '-) A blog post we did when the Government filed its opposition to our motion should do the trick for you. (I'm insanely busy, else I'd just type something.) https://www.eff.org/node/74486 -- James S. Tyre Law Offices of James S. Tyre 10736 Jefferson Blvd., #512 Culver City, CA 90230-4969 310-839-4114/310-839-4602(fax) jst...@jstyre.com Policy Fellow, Electronic Frontier Foundation https://www.eff.org -Original Message- From: Bernard Tyers - ei8fdb [mailto:ei8...@ei8fdb.org] Sent: Wednesday, June 12, 2013 2:14 PM To: James S. Tyre Subject: Re: [liberationtech] The government is no longer the only party to win a matter in the FISA Court -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi James, For the none legal experts amongst us, I wonder if is it possible to give a summary of this case? I'm reading the words but they're not making much sense! Thanks, Bernard On 12 Jun 2013, at 21:43, James S. Tyre wrote: Now EFF has too. https://www.eff.org/document/fisc-opinion-and-order-granting-effs-mo tion - -- Bernard / bluboxthief / ei8fdb IO91XM / www.ei8fdb.org -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJRuOSSAAoJENsz1IO7MIrr0moH/0ol+mqebUYNtYFwmQymw1Ly 86jfLGA2OFvIYXVs8zBOF+GOlZZN7qYA6OPC2kUwKVlhwldmnk9dNS7DePGhd4Yg TvlMIBydPtl0922zkQo9zFkSym/9I0OxZSwEpIPYlHDzhhzmJh7g9xDKdApe+fTx ZqQ/MHCCX4HhWknpYqngv9HMKW4cjHz5ZYcI5BNjb/l7W7/isrqXc8sPDsR+m6pa 8ayv+lMZewvyo9NIZFtSCH/cJ8mWpspoQNqnHRYBekxwIiXizISggxxF2/tOjv6h Re76cmvLJSCN/LYhBwLEY9J2Uv8uJABOXF73iohYh/+sAIPiaV6anTFCD6EjbGo= =uWSB -END PGP SIGNATURE- -- Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech
[liberationtech] Community Wireless Across America
From: Preston Rhea preston.r...@gmail.com I need your help for a project that will bring me to 10 cities to teach folks how to organize mesh networks. I'd like to contact the brigade captains and organizers in these cities to build relationships: Bay Area Reno Salt Lake City Denver Omaha Chicago Cleveland Pittsburgh Martinsburg DC My proposal, Community Wireless Across America (http://crowdhitch.millennialtrain.co/campaign/detail/1330), is to teach civic technologists in those 10 cities how to organize and maintain wireless mesh networks. We'll share tools and methods for participatory technology pedagogy, and the routers that we set up together will remain with people in those cities to seed their own mesh networks. With these seeds spread, organizers and technologists can continue to grow locally-managed networks and spur innovation on a shared platform accessible to any resident. In order to do the project, I have to raise $9,000 by July 1. That’s $900 per city - hoping that CfA participants will be interested in coming out to learn and spread decentralized access to the Internet and local platforms. Here is more about the Millennial Trains Project (http://millennialtrain.co/) and my donation page: http://crowdhitch.millennialtrain.co/campaign/detail/1330 Cheers and looking forward to hearing from you, Preston -- Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech
[liberationtech] Spies Without Borders : Using Domestic Networks to Spy on the World.
Find below two of our Spies Without Borders posts looking into how the information disclosed in the NSA leaks affect the international community. * Spies Without Borders : Using Domestic Networks to Spy on the World. By Tamir Israel (CIPPIC) and Katitza Rodriguez (EFF) * https://www.eff.org/deeplinks/2013/06/spies-without-borders-i-using-domestic-networks-spy-world * International Customers: It's Time to Call on US Internet Companies to Demand Accountability and Transparency. By Eva Galperin (EFF) * https://www.eff.org/deeplinks/2013/06/spy-without-borders -- Katitza Rodriguez International Rights Director Electronic Frontier Foundation kati...@eff.org kati...@datos-personales.org (personal email) Please support EFF - Working to protect your digital rights and freedom of speech since 1990 -- Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech
Re: [liberationtech] [cryptography] [ipv6hackers] opportunistic encryption in IPv6
On Tue, Jun 11, 2013 at 8:45 AM, Eugen Leitl eu...@leitl.org wrote: From: Jim Small jim.sm...@cdw.com To: IPv6 Hackers Mailing List ipv6hack...@lists.si6networks.com Better-Than-Nothing Security: An Unauthenticated Mode of IPsec http://tools.ietf.org/html/rfc5386 Thanks - I was not aware of that. So BTNS is interesting - but it doesn't solve the above problems. Per the RFC, BTNS doesn't authenticate peers. It would seem that secure key distribution (maintain confidentiality, integrity, and authentication) remains a vexing problem. You also need RFC5660, IPsec Channels. I.e., a guarantee of continuity of peer IDs for the lifetime of a connection. *Then* you can use channel binding to whatever application-layer authentication mechanism you have, *or* you can use TOFU and insist on the same key/CA/whatever next time you talk to the same peer. There have been many proposed ways of doing roughly the same thing. To my knowledge not one has succeeded wildly. RFC5660 has not been implemented. Lacking IPsec channels one needs something like CGA to ensure peer key/ID continuity, as otherwise IPsec only authenticates individual packets (and their senders), not *packet flows*, which wouldn't be a problem if IP addresses weren't assigned dynamically. Nico -- -- Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech
Re: [liberationtech] [cryptography] [ipv6hackers] opportunistic encryption in IPv6
[BTW, thanks Eugen for forwarding these posts!] Date: Wed, 12 Jun 2013 09:34:11 -0700 From: Tim tim-secur...@sentinelchicken.org To: IPv6 Hackers Mailing List ipv6hack...@lists.si6networks.com Subject: Re: [ipv6hackers] opportunistic encryption in IPv6 [...] S many different attempts at creating encryption protocols have utterly failed, and in most cases, it is because the designers have put the cart before the horse. They've started with the easy encryption problem rather than addressing the hard authentication problem. Many protocols separate key exchange and authentication. E.g., SSHv2 and TLS (when using DH for key exchange). Combining the two (e.g., by using RSA key transport) can be a nice optimization (though you might lose PFS), but IMO it's best to think of the two things as distinct and attempt only for round-trip optimization (i.e., don't incur an extra round-trip as a result of treating key exchange and authentication as separate). Indeed, you may be able to convince the world at some point to adopt opportunisitic encryption without authentication, since so many people don't understand that it doesn't buy you anything. But then they'll be shocked when the first guy writes and releases a MitM tool for it. TOFU has a decent track record. It doesn't scale, and you do need users to know how to handle key rollover, but otherwise it's pretty good. [...] As an aside: the idea embodied in CGAs is a powerful one: By making my address my key (signature), I'm implicitly binding my key to my protocol. However, CGAs address this problem at network layer, not at the human layer. So all it takes to bypass it is to MitM the protocol that hands out addresses for hosts. However, as a building block, it could be useful. Also, for those who aren't familiar with it, I strongly urge you to read up on Identity Based Encryption, where any string can be a public key, within a predefined authentication realm. I see CGA as an attempt to deal with a serious API-ish shortcoming of IPsec: there's no APIs (socket options, whatever) by which to a) influence policy to apply, b) specify who you want the peer to be, c) find out who the peer is, d) find out what policy (e.g., transforms) got applied, e) guarantee peer key/ID continuity for the lifetime of a packet flow (connection). (a) through (e) are standard features of security protocols layered above TCP/UDP/SCTP: TLS, DTLS, SSH, ... But IPsec lacks them utterly. This makes IPsec useless for end-to-end (as opposed to VPN) use except in very small deployments where static addressing makes it possible to make up for the lack of those features via policy (i.e., without the application having any visibility). There is one Internet standards-track application protocol that depends on IPsec: iSCSI. So that sucks, but fortunately iSCSI doesn't need to scale to Internet scale -- just data center scale. The only way to get IPsec APIs would be to go implement one for enough OSes. And then you'd need to get deployment, which would mean getting apps to use these APIs. That's a lost cause. Opportunistic encryption is inherently a difficult thing to pull off because opportunistic is roughly transparently, which I take to mean no UI. But authentication without any form of UI (e.g., because it takes place at a layer that lacks information like the URI of a resource a user wants loaded, or that lacks the ability to interact with the user) is a contradiction in terms. Opportunistic encryption, then is inherently susceptible to MITM attacks, and the only way I see to fix that is to provide the necessary interfaces across layers so that at least TOFU can be implemented. Nico -- -- Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech
Re: [liberationtech] Blogpost: learning lessons from NSA's PRISM (or: crypto decentralization vs. bulk spying)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 06/12/2013 11:17 AM, KheOps wrote: Dear all, I spent some time writing a blogpost aimed at not-so-aware people who may have heard about PRISM but lack the background knowledge about massive surveillance and as such could make incorrect decisions if trying to protect themselves. https://words.ceops.eu/posts/Learning%20the%20lesson%20from%20NSA%27s%20PRISM:%20don%27t%20do%20it%20wrong/ I wrote it with the hope that it'll be useful and improve the understanding of these people. Definitely +1! Excellent article. Just what the community needs. Easy to understand and doesn't require an enormous amount of tech or security knowledge to grasp. Good job! Anthony - -- Anthony Papillion Phone: 1.918.533.9699 SIP: sip:cajuntec...@iptel.org iNum:+883510008360912 XMPP:cypherpun...@jit.si www.cajuntechie.org -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCgAGBQJRuQxIAAoJEAKK33RTsEsVOvYP/0Ve+/a76UHPHqHv4BVAb1X0 uJmhP/4FIqWtfnpC4OMCe2+jGJE2ZVtZAWsuF16ljBUR7b6V7H2or0SRPAmZq6oh AN3h+VAzLpSn1LopLL7pCmmX6WuK4TlPz6pQHILA40A50aQefAkTjkN2DBsVGPR2 HBgDC7zYklFCs6O2S0SmMaqVbvgcFc2AW8D5jKNluFzq7GwJRNemWv9YSwIvS/AA dSzUa57Bhxoav09nu3t1cMbnIYe9DU5Bh8+yAlr9WB1jKzkc5zFwrfE3er3bo3O1 Uz9Vqb2qubb61C7tJuAHsHMRUBAxJHf1Sb3gcetvl/w6cMnJ96Mj2DvGm4Fq6qAc nHZHTvTTNP3px6I6j6/oKSMOWFzM1HzwKXj7mWwdDTElnvu1s8eoQNq3dtYbckeQ Uim+6pGyGJdWlBnqT1+1oZtupzHasaJjx23Qao2ONb7cbUEj3pmxriZ8X7Xo4Pi1 F8Oyzl5vcMOKXhYIgigtRvUxes/Fb2fPjf+29VBBvZzAc6q6MLSACYk6cLkJD6sZ wiOUk201VHyg09u+N4jilgRA3Ehzi0LwZF6K1C1PBL1i6BO12ADEq35nB42I3VAP UT39nH+MaGYz5rJ/rfEWbp/PjOIo8b9uqYFl+9vZFqvcsWM3crc82oVsdcMkj7oU jdtJb8OCx3mk6dyNGHwQ =wVwE -END PGP SIGNATURE- -- Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech
[liberationtech] New ICTD2012 Special Issue Published
From: Arlene Luck al...@law.usc.edu Information Technologies International Development has just published its latest issue at http://itidjournal.org/index.php/itid. Reflections at the Nexus of Theory and Practice: Selected Papers from ICTD2012 Jonathan Donner, Rebecca E. Grinter, Gary Marsden Special Issue Editors This Special Issue of ITID contains six articles, each drawn from the plenary papers presented at the Fifth International Conference on Information and Communication Technologies and Development hosted at the Georgia Institute of Technology in Atlanta, March 12–15, 2012. In total, 38 papers were presented at ICTD2012, 18 as plenary talks and 20 as poster presentations, all drawn from a field of 94 double-blind peer-reviewed submissions. The proceedings are available at the ACM Digital Library (http://dl.acm.org/citation.cfm?id=2160673). As editors, we selected papers for this special issue which had been particularly well-reviewed during the conference process, and which engaged a diversity of current issues in the ICTD field. The invited authors extended and modified their papers based on feedback from ICTD2012, and then participated in an additional single-blind peer review cycle with experts in the field. The six revised individual ICTD2012 papers, as well as Bailur’s review of Dutta’s Communicating Social Change: Structure, Culture and Agency, each make new stand-alone contributions to the field. However, to introduce the issue, it is worth reflecting on the papers as a set, and on the 2012 conference from which they have been drawn. One notable attribute of this year’s selections may be that a preponderance of the articles engage with the structure and trajectory of the field. The two clearest examples of this style are Dearden’s “See No Evil? Ethics in an Interventionist ICTD” and Dodson, Sterling, and Bennett’s “Considering Failure: Eight Years of ITID Research.” Each uses a review of the existing ICTD literature to explore implications and difficulties of conducting research with and among actual people and complex communities. By placing the intervention and the project near the center of ICTD practice, the two pieces support a perspective that “success” in ICTD (or perhaps at least in ICT4D) cannot be framed in terms of advances in abstract theory, but rather, in terms of an interplay of theoretical progress and positive practical impact. Two of the other articles also engage directly with the trajectory of the field, albeit in manners which depart from interventionist frame shared by the two discussed above. In “Cell Phone Analytics: Scaling Human Behavior Studies into the Millions,” Frias-Martinez and Virseda suggest a promising new methodology, rooted in the systematic analysis of large data sets, that may improve researchers’ abilities to associate estimated socioeconomic and demographic characteristics of populations with different levels and patterns of mobile phone behaviors, without drawing on often-costly or scarce individual or household-level interview data. Meanwhile, in “Anthropology, Development and ICTs: Slums, Youth, and the Mobile Internet in Urban India,” Rangaswamy and Cutrell draw on the results of an ethnographic study to highlight the centrality of “mundane, non-instrumental, and entertainment-driven needs” among resource-constrained teenagers in Hyderabad. In so doing, the authors call specifically for an integration of ICTD and anthropological perspectives, and for the broadening of an analytical frame inside ICTD to accommodate such uses. Finally there are two articles which represent recent instances of the tradition of interventionist field research in ICTD. In “Emergent Practices Around CGNet Swara: A Voice Forum for Citizen Journalism in Rural India,” Mudliar, Donner, and Thies report on the development, deployment, and appropriation of a citizen journalism platform in India. Their work is multidisciplinary, combining details of an original technical component (an interactive voice response system), with an evaluation of a specific instance of its uptake and impact (as the citizen journalism portal CGNet Swara). Patel, Savani, Dave, Shah, Klemmer, and Parikh also take a close look at an original voice-based system in “Power to the Peers: Authority of Source Effects for a Voice-Based Agricultural Information Service in Rural India.” Where Mudliar et al.’s approach is wide-ranging, integrative, and exploratory, Patel et al.’s analysis of Avaaj Otalo is a focused experimental design engaging specifically with established information processing theory. Their findings—detailing an instance in which farmers found audio tips from peers to be more compelling than the same tips coming from experts—will further fuel the growing interest in peer-to-peer forms of information provision and sharing in development. It is our belief that both types of evidence and inquiry will continue to be important for the field as it moves forward; both inform better
[liberationtech] NSA Director Alexander @ Senate Appropriations Committee (Jun 12)
U.S. Senate Committee on Appropriations (Jun 12) - Hearing on Cybersecurity: http://www.appropriations.senate.gov/ht-full.cfm?method=hearings.viewid=33dda6f9-5d83-409d-a8c5-7ada84b0c598 Complete video of the hearing and prepared testimony of each of the witnesses is linked here. This previously scheduled hearing received some press today as it was General Keith B. Alexander's first public appearance since the inception of the Snowden event. The General's prepared testimony provides a useful primer on the NSA/CSS and its relationship with Cyber Command - the US military branch active in the networked domain (PDF download): http://www.appropriations.senate.gov/ht-full.cfm?method=hearings.downloadid=6ae112a2-f7e1-4c6e-92a9-bd7b16f2824e gf -- Gregory Foster || gfos...@entersection.org @gregoryfoster http://entersection.com/ -- Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech
