Re: [liberationtech] Boundless Informant: the NSA's secret tool to track global surveillance data
On Mon, Jun 10, 2013 at 10:27:33PM +0200, Guido Witmond wrote: The big deal is that now it's become impossible to believe the lies, and that you [Americans] are forced to accept the truth. Reality check: https://twitter.com/_nothingtohide http://www.people-press.org/2013/06/10/majority-views-nsa-phone-tracking-as-acceptable-anti-terror-tactic/ No further questions, your honor. And truth hurts! Especially when you want to believe the lies. Wanting to believe is easier than facing the truth, even when deep in your heart you've known the truth for a long time. Now is the time to come clear with your conscience, end this abusive relationship and kick the abusive partner out of your life. (ie: repeal the unjust laws.) Realistically, we should be thankful for this brief flash of interest (already waning) and use it to reignite interest in stalled projects. -- 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] Boundless Informant: the NSA's secret tool to track global surveillance data
Sad but I guess true, but there has been a huge amount of learning from this particularly internationally and the reverberations on that will continue and perhaps even grow for a very very long time. M -Original Message- From: liberationtech-boun...@lists.stanford.edu [mailto:liberationtech-boun...@lists.stanford.edu] On Behalf Of Eugen Leitl Sent: Tuesday, June 11, 2013 6:21 AM To: liberationtech@lists.stanford.edu Subject: Re: [liberationtech] Boundless Informant: the NSA's secret tool to track global surveillance data On Mon, Jun 10, 2013 at 10:27:33PM +0200, Guido Witmond wrote: The big deal is that now it's become impossible to believe the lies, and that you [Americans] are forced to accept the truth. Reality check: https://twitter.com/_nothingtohide http://www.people-press.org/2013/06/10/majority-views-nsa-phone-tracking-as- acceptable-anti-terror-tactic/ No further questions, your honor. And truth hurts! Especially when you want to believe the lies. Wanting to believe is easier than facing the truth, even when deep in your heart you've known the truth for a long time. Now is the time to come clear with your conscience, end this abusive relationship and kick the abusive partner out of your life. (ie: repeal the unjust laws.) Realistically, we should be thankful for this brief flash of interest (already waning) and use it to reignite interest in stalled projects. -- 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] PRISM: NSA/FBI Internet data mining project
- Forwarded message from Scott Weeks sur...@mauigateway.com - Date: Mon, 10 Jun 2013 16:36:32 -0700 From: Scott Weeks sur...@mauigateway.com To: na...@nanog.org Subject: RE: PRISM: NSA/FBI Internet data mining project Reply-To: sur...@mauigateway.com Funny, sort of. The guy was residing in Hawaii. Apologies for the long URLs... Report: NSA contract worker is surveillance source: http://thegardenisland.com/news/state-and-regional/report-nsa-contract-worker-is-surveillance-source/article_2a88ec60-f99c-54a7-8c13-13f6852ccca6.html Hawaii real estate agent: Snowden left on May 1: http://thegardenisland.com/news/state-and-regional/hawaii-real-estate-agent-snowden-left-on-may/article_099ec0db-a823-56a0-8471-af8d7ef16e1b.html funny as well! NSA claims know-how to ensure no illegal spying: http://thegardenisland.com/news/state-and-regional/nsa-claims-know-how-to-ensure-no-illegal-spying/article_ec623964-d23a-53c6-aeb0-14bf325a7f3c.html scott - 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
[liberationtech] OHM2013 Hacker Camp: Five Whistleblowing Lectures
Hi all, this email just to notice that at OHM2013 Hacker's Camp http://ohm2013.org there will be several talks on Whistleblowing. It's very interesting to note how Whistleblowing has become an hot-topic for hackers and digital hacktivism! :-) We may need to organize a meeting other than those lectures to discuss among all various players and people interested on the topic. Program (getting updated) https://ohm2013.org/site/program/ with a summary below: Hermes Center: Digital Whistleblowing with GlobaLeaks We'll introduce Digital Whistleblowing, how it's effectively used and adapted to different context: Investigative Journalism, Activism, Corporations and Governments. The new GlobaLeaks 0.2 software will be presented with a show case of design, security principle and tips on how to use it or hack it. Volker: ADLeaks: A Secure Submission System for Online Whistleblowing Platforms This talk covers the design and current state of implementation of a submission system for online whistleblowing platforms that is meant to provide anonymity against end-to-end traffic analysis. Annie Machon: The three wars (terrorism, drugs, internet) Based on her own experiences as an Intelligence Officer for MI5 (the UK domestic security service) and a whistleblower Annie Machon will talk about the relationships between the wars on 'terror', drugs and the internet. Sander Venema: Howto Build a Whistleblower's Website: Maintaining Your Users' Privacy vs. Getting the Message Out This talk is about the possible conflict between getting your message out there, and trying to maintain your site visitor's privacy. This talk will highlight some of the issues that need to be taken into consideration when building websites for whistleblowers with high security privacy needs. Dr Suelette Dreyfus: Whistleblowing in the Digital Age -- What the public thinks How do different cultures perceive whistleblowing? This talk compares citizens' attitudes toward whistleblowing across several different countries. It will also reveal early results on public attitudes to using social media to blow the whistle, from the World Online Whistleblowing Survey. Finally it reviews some of the advances, proposed or actual, for whistleblowing laws in different countries. -- 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] Boundless Informant: the NSA's secret tool to track global surveillance data
On Mon, Jun 10, 2013 at 01:48:23PM -0700, x z wrote: @Rich, those are good movie scripts :-). But it does not work for 9 firms, and hundreds of execs all with diverse values and objectives. Two responses. hundreds? Not necessary. Not desirable, from the NSA's point of view, either. One person per firm would suffice, and they need not be an executive. Surely you can't think for a moment that the NSA is incapable of placing its own people on the datacenter staff of any major operation? Second, how's this for a movie script? (quoting myself) Ad I'd also, by the way, develop custom lookalike hardware. (With the NSA's budget, this could be done with chump change.) Who's going to open up a Cisco router and yank a board and look at it closely enough to figure out that it didn't come from Cisco? Now quoting this (h/t to Rob Slade): http://www.scribd.com/doc/95282643/Backdoors-Embedded-in-DoD-Microchips-From-China This paper is a short summary of the first real world detection of a backdoor in a military grade FPGA. Using an innovative patented technique we were able to detect and analyse in the first documented case of its kind, a backdoor inserted into the Actel/Microsemi ProASIC3 chips. The backdoor was found to exist on the silicon itself, it was not present in any firmware loaded onto the chip. Using Pipeline Emission Analysis (PEA), a technique pioneered by our sponsor, we were able to extract the secret key to activate the backdoor. This way an attacker can disable all the security on the chip, reprogram crypto and access keys, modify low-level silicon features, access unencrypted configuration bitstream or permanently damage the device. Clearly this means the device is wide open to intellectual property theft, fraud, re-programming as well as reverse engineering of the design which allows the introduction of a new backdoor or Trojan. Most concerning, it is not possible to patch the backdoor in chips already deployed, meaning those using this family of chips have to accept the fact it can be easily compromised or it will have to be physically replaced after a redesign of the silicon itself. ---rsk -- 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] OHM2013 Hacker Camp: Five Whistleblowing Lectures
On Tue, 11 Jun 2013 13:21:49 +0200 Fabio Pietrosanti (naif) li...@infosecurity.ch wrote: We may need to organize a meeting other than those lectures to discuss among all various players and people interested on the topic. Maybe the Free Village[1] could accommodate a meeting like that, it certainly sounds like the right place. This assumes, of course, that there is enough space for everybody and whoever organizes that village is willing to do so. [1] https://ohm2013.org/wiki/Village:Free_Village -- 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] Edward Snowden has gone missing
http://www.theatlanticwire.com/national/2013/06/where-is-edward-snowden/66072/ I'm reminded of this exchange, which I presume everyone on this list is familiar with: I'd like to go back to New York. You have not much future there. It will happen this way: you may be walking, maybe the first sunny day of spring. And a car will slow beside you, and a door will open and someone you know, even trust, will get out. And he will smile, a becoming smile. But he will leave open the car door and offer to give you a lift. ---rsk -- 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] OHM2013 Hacker Camp: Five Whistleblowing Lectures
Hey Fabio and others, Our village Noisy Square (formely known as the Free Village or TA Pown OHM) is open for these kind of meetings. Parts of the village can be opened or closed to cater towards the privacy needs of participants in such meetings. Contact me for details. Anyone else interested in becoming part of this village; we'll have a call for participants ready this week and it will be send out on this list and others. All the best, Douwe Schmidt - - - - - - - - - - - https://greenhost.nl - @greenhost - +31204890444 - chat: do...@jabber.greenhost.nl gpg: 8213 EE0B 65AF 926C 4A96 9BA2 4CC1 7E8E 84CC 39C5 - - - - - - - - - - - On 11 6 2013, at 13:28, phryk in...@phryk.net wrote: On Tue, 11 Jun 2013 13:21:49 +0200 Fabio Pietrosanti (naif) li...@infosecurity.ch wrote: We may need to organize a meeting other than those lectures to discuss among all various players and people interested on the topic. Maybe the Free Village[1] could accommodate a meeting like that, it certainly sounds like the right place. This assumes, of course, that there is enough space for everybody and whoever organizes that village is willing to do so. [1] https://ohm2013.org/wiki/Village:Free_Village -- 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] Boundless Informant: the NSA's secret tool to track global surveillance data
On 11-06-13 12:21, Eugen Leitl wrote: On Mon, Jun 10, 2013 at 10:27:33PM +0200, Guido Witmond wrote: The big deal is that now it's become impossible to believe the lies, and that you [Americans] are forced to accept the truth. Reality check: https://twitter.com/_nothingtohide http://www.people-press.org/2013/06/10/majority-views-nsa-phone-tracking-as-acceptable-anti-terror-tactic/ No further questions, your honor. 1st step to recovery is denial... However, the question of Pew Research (in that second link) is not fair: Which is more important? A. Investigate terrorist threats; (or) B. Not intrude on privacy (of the general public) There is a third choice: C. Investigate terrorist threats AND not intrude on privacy (of the general public). We pay you people $X Billion dollars to do so. I tend to agree with Lauren Weinsteins opinion that it is rampant paranoia that lead us (the world) into this. http://lauren.vortex.com/archive/001044.html Realistically, we should be thankful for this brief flash of interest (already waning) and use it to reignite interest in stalled projects. I am very grateful for mr Snowden and Greenwald to leak this. Now it is ok for EU-commissioner mrv Viviane Reding to state that privavcy isn't a luxury but a right. Regards, Guido. PS: Check out the background picture on that twitter-page, sheep! -- 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 Jim Small jim.sm...@cdw.com - Date: Tue, 11 Jun 2013 01:02:54 + 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 Hi Owen, The fundamental challenge for encryption is key distribution and management: * How do I authenticate the intended recipient(s)? This is a traditional challenge with many traditional solutions, all of which have tradeoffs, especially in M2M communications. * How do I distribute a key without letting anyone except the intended recipient(s) get it? DH pretty well solves this, no? Yes and no. DH is a good answer, but IKE/IPsec still requires pre-shared keys or RSA key pairs to start with. So I think there would be some value in a keying system that allows some kind of controlled federation without having to depend on pre-shared keys, PKI, or DNSSec. * How do I manage the key to periodically change it while keeping it confidential? Again, DH with PFS makes this a solved problem AFAIK. True - but only after the initial hurdle of having a pre-shared key or RSA key pair. * How do I notify the recipient if the key was compromised or is otherwise invalid? This doesn't seem all that hard so long as a rekey instruction is built into the protocol. I believe that's already the case with IPSEC SAs, no? Well - if we take DH, it's true once we've established a connection. What about if we haven't? Really the question I'm asking - if we have two independent parties, how do they validate each other without a trusted 3rd party? Current options: * pre-shared keys (but not scalable and keys tend to be weak to make it easy to share - keys are rarely if ever rotated) * PKI - good but complex and as Moxie Marlinspike has demonstrated with others many flaws, abused by governments * DNSSec - interesting one to watch but not really ready for wide spread use yet, needs greater adoption * Manual/3rd party CA - possible if one party trusts the other or in a service provider scenario Did I miss any viable wide spread options? I know there are lots of theoretical ones but I'm talking about significantly deployed ones - say used by at least 1 million parties. Vs. this paper, I think that opportunistic IPSEC, ala Micr0$0ft's direct- connect or whatever they call it product is quite a bit more viable. It depends on AD as a PKI distribution mechanism for authentication. DirectAccess is neat - but it's not exactly a break through. DA is just a service based (aka UNIX/Linux daemon) IPv6 IPsec VPN with good provisioning and automatic IPv4 tunneling. It's essentially a nice packaging of certificate-based IPsec leveraging Windows Active Directory provisioning. There are some good ideas in this paper. I just think there are some things missing - at least from my cursory reading of it. --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 -- 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 Mark Smith markzzzsm...@yahoo.com.au - Date: Mon, 10 Jun 2013 21:10:06 -0700 (PDT) From: Mark Smith markzzzsm...@yahoo.com.au To: IPv6 Hackers Mailing List ipv6hack...@lists.si6networks.com Subject: Re: [ipv6hackers] opportunistic encryption in IPv6 X-Mailer: YahooMailWebService/0.8.146.552 Reply-To: IPv6 Hackers Mailing List ipv6hack...@lists.si6networks.com - Original Message - From: Jim Small jim.sm...@cdw.com To: IPv6 Hackers Mailing List ipv6hack...@lists.si6networks.com Cc: Sent: Tuesday, 11 June 2013 11:02 AM Subject: Re: [ipv6hackers] opportunistic encryption in IPv6 Hi Owen, The fundamental challenge for encryption is key distribution and management: * How do I authenticate the intended recipient(s)? This is a traditional challenge with many traditional solutions, all of which have tradeoffs, especially in M2M communications. * How do I distribute a key without letting anyone except the intended recipient(s) get it? DH pretty well solves this, no? Yes and no. DH is a good answer, but IKE/IPsec still requires pre-shared keys or RSA key pairs to start with. Don't think so anymore. Better-Than-Nothing Security: An Unauthenticated Mode of IPsec http://tools.ietf.org/html/rfc5386 Don't know if there are any implementations available. ___ 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] [ipv6hackers] opportunistic encryption in IPv6
This thread is ending, so I will limit further distribution, explicitly removing libtech. - Forwarded message from Jim Small jim.sm...@cdw.com - Date: Tue, 11 Jun 2013 04:27:33 + 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 Hi Mark, The fundamental challenge for encryption is key distribution and management: * How do I authenticate the intended recipient(s)? * How do I distribute a key without letting anyone except the intended recipient(s) get it? DH pretty well solves this, no? Yes and no. DH is a good answer, but IKE/IPsec still requires pre-shared keys or RSA key pairs to start with. Don't think so anymore. 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. 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? 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+? PKI CAs using SCEP for enrollment/management work pretty well. If you could get a key pair from DHCP or as a function of using a directory service, use it to generate a CGA, and then use that just for authentication it would already be fantastic. Just being confident that an address is authentic and not spoofed is a huge improvement over the current state for Internet security. Thoughts? --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 -- 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] Cryptocat: Translation Volunteers Needed
On 2013-06-10, at 8:21 PM, Catherine Roy ecr...@catherine-roy.net wrote: On 10/06/2013 6:18 PM, Nadim Kobeissi wrote: Catherine, Opera is not shut out. It's simply difficult to develop for Opera due to its limited browser extension API. Your email made it sound as if Cryptocat had something against the Opera browser. My email is simply stating that Opera is shut out. How else should I interpret this message : Cryptocat is not available for your browser. See screenshot : http://www.flickr.com/photos/zazie/9010759541/ I sent you a message off-list to inquire about this and received no response. We have a ticket open for Opera compatibility in our code base. If you'd like to, you can contribute to Cryptocat for Opera development here: https://github.com/cryptocat/cryptocat/issues/190 I am not a developer. Must we all be developers to have a significant influence on these types of issues ? No, you can also repeatedly send me blandly demanding emails and then take the issue to the public when I don't answer immediately, and expect me to change Cryptocat's development roadmap to accommodate for you and the 1% that use a browser with a highly limited third-party development API. Seriously, you're really frustrating. NK Best regards, Catherine -- Catherine Roy http://www.catherine-roy.net NK On 2013-06-10, at 6:10 PM, Catherine Roy ecr...@catherine-roy.net wrote: Congrats. But, as I asked in a private email to which I got not response, is there any reason why Opera is shut out ? Best, Catherine -- Catherine Roy http://www.catherine-roy.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 -- 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] Cryptocat: Translation Volunteers Needed
On 2013-06-11, at 7:31 AM, Eugen Leitl eu...@leitl.org wrote: On Mon, Jun 10, 2013 at 08:21:40PM -0400, Catherine Roy wrote: On 10/06/2013 7:37 PM, Travis McCrea wrote: Opera is being released now on Webkit, though I am sure you will still have legacy opera users... I think you could put this issue a little further down on your list. I guess using Cryptocat will also be further down my list. You will find that proprietary systems will receive less (frequently none) support. This is due to difficulties developing for proprietary systems, but also due to effective impossibility to varify security of proprietary systems. So open source is at a distinct advantage here. For an end user interested in secure communication it is always a good idea to pick the most supported platform. In case of browsers, that will be Firefox and Chromium (not Chrome), in that order of precedence. In general, browsers have giant vulnerability surfaces, and should not be used for anything serious. A little security is a dangerous thing. This has been getting a lot better very quickly, to a point where I'm optimistic about the future. Specifically I'm very excited about the situation with Chrome OS on Chromebooks. Chrome OS is currently (I believe) one of the most secure operating systems out there that still manages to be very highly functional and usable. That's why we make sure Cryptocat is specifically compatible and usable on it. I would trust Cryptocat on a Chromebook more than Pidgin-OTR on Windows/Mac/Linux any day of the week. (Of course this is only my preference, but Pidgin-OTR's sheer number of un-patched 0days and lack of auditing is still a real issue.) 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] Cryptocat: Translation Volunteers Needed
On Jun 11, 2013, at 4:07 PM, Nadim Kobeissi na...@nadim.cc wrote: On 2013-06-10, at 8:21 PM, Catherine Roy ecr...@catherine-roy.net wrote: On 10/06/2013 6:18 PM, Nadim Kobeissi wrote: Catherine, Opera is not shut out. It's simply difficult to develop for Opera due to its limited browser extension API. Your email made it sound as if Cryptocat had something against the Opera browser. My email is simply stating that Opera is shut out. How else should I interpret this message : Cryptocat is not available for your browser. See screenshot : http://www.flickr.com/photos/zazie/9010759541/ I sent you a message off-list to inquire about this and received no response. We have a ticket open for Opera compatibility in our code base. If you'd like to, you can contribute to Cryptocat for Opera development here: https://github.com/cryptocat/cryptocat/issues/190 I am not a developer. Must we all be developers to have a significant influence on these types of issues ? No, you can also repeatedly send me blandly demanding emails and then take the issue to the public when I don't answer immediately, and expect me to change Cryptocat's development roadmap to accommodate for you and the 1% that use a browser with a highly limited third-party development API. Seriously, you're really frustrating. NK TOUCHÉ: Jake, I don't agree with x z (and rather agree with you), but I'm really tired of just how aggressive and rude you always are on Libtech. And it doesn't appear to just be towards me. I'm not the only person who feels like this. Even if you're right, tone your ego knob down already. Be nice. I can barely read through threads anymore. Thank you. NK :) Best regards, Marcin -- 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 Hi Anthony, On 08/06/13 13:36, Anthony Papillion wrote: 1. Location is a particularly thorny issue. Presentations at either HOPE or BlackHat demonstrated how easy it is to locate a mobile even if you're not the government with a massive budget and mad technology. Perhaps routing the network connection through Tor may suffice? But I don't think so as something doesn't 'feel' right about that. Thoughts? Routing the call through Tor wouldn't conceal the phone's location from the mobile network. The caller and callee would both have to use cell towers to reach the Tor network, so their respective mobile networks would still know their locations, and any hacks that can currently be used to trick the mobile network into revealing a phone's location would still work. In theory you could conceal who calls whom from the mobile network by routing the call through Tor. However, in order to be able to receive calls, the callee would either have to maintain a constant connection to Tor (draining her battery and data allowance) or ask some third party with a constant connection to Tor to send her push notifications of incoming calls, which she could then answer by connecting to Tor. The third party would know when the callee was receiving incoming calls, though not necessarily from whom. Even this would reveal quite a lot of information to the mobile network. Alice starts sending data at 12:34:56. Bob receives a push notification at 12:34:57. Bob starts sending data at 12:34:58. Alice and Bob both stop sending data at 12:44:58. The inference is pretty clear: Alice called Bob at 12:34 and the call lasted ten minutes. 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. 2. Content is much easier to protect. My initial thought is to take a stock Android phone, replace the dialer with a SIP client capable of doing ZRTP, and customize the phone to tower communication so that all communication between the two is fully encrypted (and I don't mean the BS GSM encryption). Once the data gets on the network, it would be decrypted and calls would be connected. Content would be protected automatically when the user called ANY SIP device that supported ZRTP. Calls to PTSN would still be wide open. It's not practical to use a custom protocol between the phone and the tower - apart from the logistical issues of rolling out a new protocol, carriers won't adopt a protocol that lacks lawful intercept backdoors. However, phone-to-tower encryption isn't needed if you have phone-to-phone encryption, so I believe RedPhone does what you want (but I haven't used it so I could be wrong). Cheers, Michael -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAEBAgAGBQJRtzfsAAoJEBEET9GfxSfMcfoH/jPBVjyJCBKThYy/kN14ZcNX pwaOzHdpZ+MxHKo919Exu2XUn9nIHlrGB1sqL9azsxss+m/bTgfc9iXVrOXQLhNb 8fif2PYacKgZ7eyrV1lFYesDXbcpgrRkFI7qJodc3ukfgZx87pmHmogXRGGpVvGy cx7X/+tXBPqi84Sq2tDRcPdX7eDRXxjoE6DK0YG6f9+KN3aPLfoFCQZrnMUzqgcG 6zvJrpuCvSiH1Uk5UMbjDGMsXempFf5kDTbThOhYJG2Fi+kOw9cOlsFx0z2QB5Yf 0dSRrTHPYOIxA+JwI0pRxhCnEOC8SEWCmQVzpzEww8RvK2/k0x5ZFBERtetxiRg= =irF4 -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] Cryptocat: Translation Volunteers Needed
Catherine, shut out is an active verb indicating intention, which is very different from not available for which implies the potential to become available, unlike shut out which ones a decision to not provide support. That said Nadim, I do find increasing use of opera in areas of low bandwidth such as Zimbabwe and Libya. It may only be 1% of total users but might be a far larger percent of likely users or users you intend to reach. That said I know nothing about the technical issues and assume u have investigated them. Brian On Jun 11, 2013 2:19 AM, Catherine Roy ecr...@catherine-roy.net wrote: On 10/06/2013 6:18 PM, Nadim Kobeissi wrote: Catherine, Opera is not shut out. It's simply difficult to develop for Opera due to its limited browser extension API. Your email made it sound as if Cryptocat had something against the Opera browser. My email is simply stating that Opera is shut out. How else should I interpret this message : Cryptocat is not available for your browser. See screenshot : http://www.flickr.com/photos/**zazie/9010759541/http://www.flickr.com/photos/zazie/9010759541/ I sent you a message off-list to inquire about this and received no response. We have a ticket open for Opera compatibility in our code base. If you'd like to, you can contribute to Cryptocat for Opera development here: https://github.com/cryptocat/**cryptocat/issues/190https://github.com/cryptocat/cryptocat/issues/190 I am not a developer. Must we all be developers to have a significant influence on these types of issues ? Best regards, Catherine -- Catherine Roy http://www.catherine-roy.net NK On 2013-06-10, at 6:10 PM, Catherine Roy ecr...@catherine-roy.net wrote: Congrats. But, as I asked in a private email to which I got not response, is there any reason why Opera is shut out ? Best, Catherine -- Catherine Roy http://www.catherine-roy.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/**liberationtechhttps://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] Cryptocat: Translation Volunteers Needed
To be honest, if you are not in a situation that needs cryptocat anyway, and Nadim doesn't make any money from you using cryptocat... and it means less hostile bug reports from you... why would he want you to? No one is forced to use the program, yes, Opera might be used by people we would like to target but as said earlier Opera is coming out real soon with a new version that will be compatible. Why waste effort to support a legacy browser, when he could be focusing his time on making cryptocat better for everyone? I don't speak for CryptoCat so don't use my words against them, I just don't really see why people are getting all agro. We are all on the same team. Catherine Roy wrote: On 11/06/2013 10:07 AM, Nadim Kobeissi wrote: On 2013-06-10, at 8:21 PM, Catherine Roy ecr...@catherine-roy.net wrote: I am not a developer. Must we all be developers to have a significant influence on these types of issues ? No, you can also repeatedly send me blandly demanding emails and then take the issue to the public when I don't answer immediately, and expect me to change Cryptocat's development roadmap to accommodate for you and the 1% that use a browser with a highly limited third-party development API. Seriously, you're really frustrating. For the record, I sent you one very polite email off list 3 days ago to which you never replied. My 2 emails to this list were not blandly demanding either, they were simple and to the point. I do not think any of my messages warranted this type of reply. And neither did they warrant me being insulted off list by someone else from this list. Browser optimization is not something to take lightly and basically dismissing someone by telling them to go contribute code on github is not the best way to handle things either (like I said not everyone is a developer and users should be able to inquire about and request changes regardless). Indeed Opera is perhaps not the browser with the most market share globally (1.52% atm) but by effectively shutting it out, you are ignoring many eastern european countries, among other things. Anyhow, I do use other browsers out of necessity, including Chrome, Chromium and Firefox. But with such user/customer relations, I will not be going to the trouble of taking them out for your product. Best regards, Catherine -- 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] OHM2013 Hacker Camp: Five Whistleblowing Lectures
Hi Fabio et al, My talk is about computer forensics, but many of the examples used are specific to whistleblowing. I will also be giving at least one short workshop on document forensics specifically. Keep an eye out for Do You Want To Know A Secret: A Brief History of Computer Forensics And I will be in Noisy Square as well, hacking on stuff and cooking (though perhaps not in that space). =) best, Griffin Boyce -- Just another hacker in the City of Spies. #Foucault / PGP: 0xAE792C97 / OTR: sa...@jabber.ccc.de My posts, while frequently amusing, are not representative of the thoughts of my employer. -- 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: liberationtech liberationtech@lists.stanford.edu Sent: Tuesday, June 11, 2013 10:45 AM Subject: Re: [liberationtech] Building a encrypted mobile network -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Anthony, On 08/06/13 13:36, Anthony Papillion wrote: 1. Location is a particularly thorny issue. Presentations at either HOPE or BlackHat demonstrated how easy it is to locate a mobile even if you're not the government with a massive budget and mad technology. Perhaps routing the network connection through Tor may suffice? But I don't think so as something doesn't 'feel' right about that. Thoughts? Routing the call through Tor wouldn't conceal the phone's location from the mobile network. The caller and callee would both have to use cell towers to reach the Tor network, so their respective mobile networks would still know their locations, and any hacks that can currently be used to trick the mobile network into revealing a phone's location would still work. In theory you could conceal who calls whom from the mobile network by routing the call through Tor. However, in order to be able to receive calls, the callee would either have to maintain a constant connection to Tor (draining her battery and data allowance) or ask some third party with a constant connection to Tor to send her push notifications of incoming calls, which she could then answer by connecting to Tor. The third party would know when the callee was receiving incoming calls, though not necessarily from whom. Even this would reveal quite a lot of information to the mobile network. Alice starts sending data at 12:34:56. Bob receives a push notification at 12:34:57. Bob starts sending data at 12:34:58. Alice and Bob both stop sending data at 12:44:58. The inference is pretty clear: Alice called Bob at 12:34 and the call lasted ten minutes. 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.). It's reinventing old technology: the landline and the answering machine. But users would avoid the new surveillance problems with metadata leaking. Whoever is planning the Restore the Fourth Amendment project would certainly make use of such a system if it existed and was usable. -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] New Anonymity Network for Short Messages
Hello all, I have created a simple anonymity network that broadcasts all messages to participants so that you cannot associate chatters. https://bitbucket.org/scassidy/dinet There is a simple sample client available, but you could write your own client to build your own features atop the network. http://projects.existentialize.com/dinet/client.html Please let me know if you have any comments. Sean -- 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
It would be a fairly simple task to review all of the chat information and correlate call and response for all of the conversations. ~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] New Anonymity Network for Short Messages
Hi. I took a quick look while procrastinating at work and found a few potential issues: - What's up with this hard-coded salthttps://bitbucket.org/scassidy/dinet/src/9f3afe465afb124367e03b63c6b63cba261e4edf/client/broadcast_client.c?at=master#cl-16 ? - Any specific reason you picked CTRhttps://bitbucket.org/scassidy/dinet/src/9f3afe465afb124367e03b63c6b63cba261e4edf/client/broadcast_client.c?at=master#cl-88 ? - Use mlockhttps://bitbucket.org/scassidy/dinet/src/9f3afe465afb124367e03b63c6b63cba261e4edf/client/broadcast_client.c?at=master#cl-238 here? I don't think that will help you if you run within a guest VM though. - Buffer overflowhttps://bitbucket.org/scassidy/dinet/src/9f3afe465afb124367e03b63c6b63cba261e4edf/client/broadcast_client.c?at=master#cl-241on password input - Is this safe for non-terminated stringshttps://bitbucket.org/scassidy/dinet/src/9f3afe465afb124367e03b63c6b63cba261e4edf/common.c?at=master#cl-41 ? - Why do you have this checksumhttps://bitbucket.org/scassidy/dinet/src/9f3afe465afb124367e03b63c6b63cba261e4edf/client/broadcast_client.c?at=master#cl-112if you just HMACed the ciphertext? - HMAC verification is vulnerable to a timing attackhttps://bitbucket.org/scassidy/dinet/src/9f3afe465afb124367e03b63c6b63cba261e4edf/client/broadcast_client.c?at=master#cl-129. Since you're using CTR, it's that much easier to forge messages. - There's no forward security. This is by no means comprehensive. I've only been looking at a couple files. On Tue, Jun 11, 2013 at 9:52 AM, Sean Cassidy sean.a.cass...@gmail.comwrote: Hello all, I have created a simple anonymity network that broadcasts all messages to participants so that you cannot associate chatters. https://bitbucket.org/scassidy/dinet There is a simple sample client available, but you could write your own client to build your own features atop the network. http://projects.existentialize.com/dinet/client.html Please let me know if you have any comments. Sean -- 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] [cryptopolitics] [cryptography] skype backdoor confirmation
- Forwarded message from Adam Back a...@cypherspace.org - Date: Tue, 11 Jun 2013 19:28:44 +0200 From: Adam Back a...@cypherspace.org To: Ethan Heilman eth...@gmail.com Cc: Crypto discussion list cryptogra...@randombit.net, New Cpunks List cryptopolit...@randombit.net Subject: Re: [cryptopolitics] [cryptography] skype backdoor confirmation User-Agent: Mutt/1.5.21 (2010-09-15) Reply-To: New Cpunks List cryptopolit...@randombit.net (I set the reply to to the cryptopolitics/new cypherpunk list). It seems skype via PRISM/NSA api or intermediate server complying with a FISA order they probably couldnt talk about if they wanted to, is recording pretty much everything in skype channels, maybe narrowed only by bandwidth. It doesnt seem that US citizens are particularly safe either, though not being from the US I'm even less than 51% assured anyway. Great and 100% full-on analysis for the rest of the world. In fact it seems what is really going on is they record everything to preserve ability for retro-active analysis, US non-US. According to EFF in NSA terminology data isnt collected until its pulled from the NSA data farm and analysed in some way. Obvioulsy to other readers of the English language, collected is when it hits the disk in NSA's Utah exabyte disk farm. So the 51% assurance I would think is actually that they havent yet analysed your data (for US users), not that they didnt record it. Curiously many journalists and commentators seem to be suffering from repeated extremely naive failure to parse PR-speak. They need to read more from Binney and re-listen to Snowden. You cant expect to reverse engineer the architecture of something from a PR expert who is intentionally lying to you. (Lying is defined as an intent to mislead, and they lied to everyone including the authors of the Patriot act, congress, the oversight committees, etc. Clapper calls it (actual TV interview quote) least untruthful manner ie he didnt say anything directly untrue during his previous successful attempts to mislead congress in congressional hearings.) Anyway a small tidbit related to the pre-prism discussion of skype suspected backdooring (and probably thats pretty much conclusive given the PRISM disclosures): This article says skype had handed over web browsing information: http://www.guardian.co.uk/technology/2013/jun/11/uk-intelligence-requests-microsoft-data But more than 7,000 British requests resulted in data being shared, including names, addresses and browsing history showing a list of websites visited by a Microsoft customer So given the context being skype, I am thinking that we're just checking for malware URL uploading is actually recorded and subject to supoena for normal law enforcement, and mass storage/retro-active analysis by law enforcement. Probabl along with the rest of the IM stream. Back to the PRISM saga, I think the NSA and echelon partners have overstepped the mark massively and built a MONSTROSITY that may eventually bring down democracy. Its probably more fragile than people think; some european democracies are relatively young, and civil unrest and dangerous political voices seem to gain in times of extreme economic and political stress as in greece (golden dawn neo-nazis). No doubt the prime PRISM motivations were profit (defense contractors with big lobbing influence in the post 9-11 world) plus a bit of national security, chasing the odd bad guy. But for proportionality in cost (the number of people killed by terrorists is a tiny tiny risk for western countries), and erosion of civil liberties (4th amendment to americans) this is an outrage. Many people died historically fighting to rid the world of such facist governments. We should not glibly build the means of democracies downfall. The most dangerous aspect is the secerecy - not only do they want to collect the biggest dossier on everyone ever, they want to do it in secret, with secret courts, secret legal interpretations, and gag orders on those in industry forced to participate. Secret laws are not hallmarks of a democratic process. Adam On Thu, Jun 06, 2013 at 06:23:16PM -0400, Ethan Heilman wrote: From the new Washington Post Article According to a separate Users Guide for PRISM Skype Collection, that service can be monitored for audio when one end of the call is a conventional telephone and for any combination of audio, video, chat, and file transfers when Skype users connect by computer alone. Googles offerings include Gmail, voice and video chat, Google Drive files, photo libraries, and live surveillance of search terms. ___ cryptopolitics mailing list cryptopolit...@randombit.net http://lists.randombit.net/mailman/listinfo/cryptopolitics - End forwarded message - -- Eugen* Leitl a href=http://leitl.org;leitl/a http://leitl.org __ ICBM: 48.07100,
Re: [liberationtech] New Anonymity Network for Short Messages
On Tue, Jun 11, 2013 at 10:10 AM, Griffin Boyce griffinbo...@gmail.com wrote: It would be a fairly simple task to review all of the chat information and correlate call and response for all of the conversations. I disagree for several reasons. 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). Second is that this protocol is not necessarily one-to-one. It naturally supports one-to-many, many-to-one, and many-to-many messages. As these are not distinguished at the message layer, but rather at the application layer, it would take some more sophisticated analysis to determine the nature of the conversation. Third is that prefix selection logic is entirely up to the client. They can choose prefixes that vary with an encrypted pattern, or some variant of that idea, to obfuscate where they are sending their messages. Sean ~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] New Anonymity Network for Short Messages
On Tue, Jun 11, 2013 at 10:29 AM, Steve Weis stevew...@gmail.com wrote: Hi. I took a quick look while procrastinating at work and found a few potential issues: Thanks for taking a look. I'll be sure to incorporate your feedback. - What's up with this hard-coded salt? Lack of love for the text client. I should just delete that code. The primary user interface is the HTTP endpoint. - Any specific reason you picked CTR? CTR is widely recommended. Cryptography Engineering specifically recommends it. - Use mlock here? I don't think that will help you if you run within a guest VM though. - Buffer overflow on password input Absolutely true. - Is this safe for non-terminated strings? Gah, must have missed that in my review. - Why do you have this checksum if you just HMACed the ciphertext? This checksum is an important part of DiNet. Each packet comes with a checksum that each router uses to verify the message integrity (not authenticate, mind you) and to make sure it hasn't seen this message before. As each router sends every packet it hasn't seen recently to every machine that is connected to it, it is important to not re-send data. - HMAC verification is vulnerable to a timing attack. Since you're using CTR, it's that much easier to forge messages. I will have to look into this in my Javascript client as well. Do you have any recommendations? - There's no forward security. I am aware. This is a feature I would love to add to the Javascript client. This is by no means comprehensive. I've only been looking at a couple files. Thanks for looking! I appreciate the feedback. Sean On Tue, Jun 11, 2013 at 9:52 AM, Sean Cassidy sean.a.cass...@gmail.com wrote: Hello all, I have created a simple anonymity network that broadcasts all messages to participants so that you cannot associate chatters. https://bitbucket.org/scassidy/dinet There is a simple sample client available, but you could write your own client to build your own features atop the network. http://projects.existentialize.com/dinet/client.html Please let me know if you have any comments. Sean -- 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] New Anonymity Network for Short Messages
On 11 June 2013 13:42, Sean Cassidy sean.a.cass...@gmail.com wrote: On Tue, Jun 11, 2013 at 10:10 AM, Griffin Boyce griffinbo...@gmail.com wrote: It would be a fairly simple task to review all of the chat information and correlate call and response for all of the conversations. I disagree for several reasons. 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). Second is that this protocol is not necessarily one-to-one. It naturally supports one-to-many, many-to-one, and many-to-many messages. As these are not distinguished at the message layer, but rather at the application layer, it would take some more sophisticated analysis to determine the nature of the conversation. Third is that prefix selection logic is entirely up to the client. They can choose prefixes that vary with an encrypted pattern, or some variant of that idea, to obfuscate where they are sending their messages. I haven't looked at your project much (sorry, I've added it to my list though ;) ) - but Griffin is right to be paranoid first. Depending on the metadata available*, it is often possible to correlate messages with some good amount of probability, even when it seems like a flood of random messages. I like the idea of shared inboxes, for all their faults, and will be talking about faults and these types of correlation attacks at Defcon this summer, targeting perhaps the largest shared inbox-based anonymity project deployed: https://www.defcon.org/html/defcon-21/dc-21-speakers.html#Ritter -tom *It's amusing that the focus of this (and my) analysis completely discards looking at actual content, and focuses entirely on metadata. Metadata, Metadata, Metadata. ;) -- 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
Comments inline... On Tue, Jun 11, 2013 at 10:47 AM, Sean Cassidy sean.a.cass...@gmail.comwrote: - Any specific reason you picked CTR? CTR is widely recommended. Cryptography Engineering specifically recommends it. The reason I ask is that this makes your IV-generation more critical than, say, CBC, XTS, or other modes. If you have an IV collision, you'll leak some message bits. How big is the random nonce here, i.e. sizeof(dp.id.id) - blenhttps://bitbucket.org/scassidy/dinet/src/9f3afe465afb124367e03b63c6b63cba261e4edf/client/broadcast_client.c?at=master#cl-84? How are message IDs generated? - HMAC verification is vulnerable to a timing attack. Since you're using CTR, it's that much easier to forge messages. I will have to look into this in my Javascript client as well. Do you have any recommendations? Use a timing-independent array comparisonhttp://rdist.root.org/2010/01/07/timing-independent-array-comparison/. It's an easy fix. I've made the same mistake before, which is why I always look for it now. -- 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 Tue, Jun 11, 2013 at 9:52 AM, Sean Cassidy sean.a.cass...@gmail.com wrote: I have created a simple anonymity network that broadcasts all messages to participants so that you cannot associate chatters. https://bitbucket.org/scassidy/dinet See also: https://bitmessage.org/wiki/Main_Page (I have some reservations about the design-as-of-last-I-looked: The round trip required to obtain the far-end's public key significantly degrades the security properties— but they've been actively developing it, so that may well have been fixed by now). -- 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] [cryptopolitics] [cryptography] skype backdoor confirmation
On Tue, Jun 11, 2013 at 07:31:59PM +0200, Eugen Leitl wrote: democracies downfall. The most dangerous aspect is the secerecy - not only do they want to collect the biggest dossier on everyone ever, they want to do it in secret, with secret courts, secret legal interpretations, and gag orders on those in industry forced to participate. Secret laws are not hallmarks of a democratic process. https://fbcdn-sphotos-a-a.akamaihd.net/hphotos-ak-prn1/943487_324377737694270_933715187_n.jpg :) -- __ [Pavol Luptak, Nethemba s.r.o.] [http://www.nethemba.com] [tel: +421905400542] -- 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
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
Re: [liberationtech] New Anonymity Network for Short Messages
On Tue, Jun 11, 2013 at 11:42 AM, Griffin Boyce griffinbo...@gmail.com wrote: 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. This is mitigated (somewhat) by allowing the users to filter the amount of messages they can receive by the length of the prefix they specify. The shorter the prefix, the more messages and more anonymous it becomes, but if bandwidth is a concern you can increase your prefix length to lower your bandwidth consumption. The fixed message size addresses this somewhat as well. Sean ~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] New Anonymity Network for Short Messages
On Tue, Jun 11, 2013 at 11:13 AM, Gregory Maxwell gmaxw...@gmail.com wrote:
On Tue, Jun 11, 2013 at 9:52 AM, Sean Cassidy sean.a.cass...@gmail.com
wrote:
I have created a simple anonymity network that broadcasts all messages
to participants so that you cannot associate chatters.
https://bitbucket.org/scassidy/dinet
See also: https://bitmessage.org/wiki/Main_Page
(I have some reservations about the design-as-of-last-I-looked: The
round trip required to obtain the far-end's public key significantly
degrades the security properties— but they've been actively developing
it, so that may well have been fixed by now).
A friend of mine sent me this as well when I told him about it. My
main concern with Bitmessage is the size and complexity of the
protocol. My protocol is just a struct:
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
};
Should be easier to analyze and study, I would think.
Sean
--
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] Russia and PRISM?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On second thought, disregard this. Prizma is a fairly standard social media analytics platform. It has none of the features of PRISM that have come out in the past week. On 06/08/2013 05:52 PM, Peter Bourgelais wrote: Hello again libtech, First, sorry for replying out of thread again, I have different settings on this email and it shouldn't happen again. Late last year, I heard about a data mining system in use by the Russian authorities called Prizma. Here are some links, and Google Translate is your friend: http://www.forbes.ru/sobytiya/vlast/92590-kak-vlasti-chitayut-vashi-blogi-rassledovanie-forbes http://roem.ru/2012/08/16/prizma52924/ http://www.mlg.ru/solutions/4executives/prizma/ Anyone else want to speak to this? -Peter Bourgelais Tech Fellow AccessNow.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJRt4SqAAoJENkgSO8zvZYxCQ8IAJp4GSkglWrgkgbaB5rkVncL TG3C3/LDhixVm74ECwn00/AtsJf7lLJQX6xwe+wUk2gc6U8SdbU2CyKsWfC8lUAA sREtwP4+uW4RVNXXmy3UYmjae+sD2lmg7FaDRu7mS7PKo0+eZto/2qFEyFxFhRHO cI76qhuo649getE8QRYXReb51vaWJqaxxwfE4pbxIfO7qTwJ/s9sy++jDYgrGumM txgF6pxXATLpgypUjfE71yLsVG6fkdJhpEnKm+G5OdayvOYcmVD+LwbI7prPXaLs U6AA/jscK6dEED6CiPYoCH5WVYA6s93eXPN8kSpT1jGpYPk6+O92UgXpNcqfG3k= =rMgq -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
Steve Weis: Comments inline... On Tue, Jun 11, 2013 at 10:47 AM, Sean Cassidy sean.a.cass...@gmail.comwrote: - Any specific reason you picked CTR? CTR is widely recommended. Cryptography Engineering specifically recommends it. I was puzzled by this recommendation. CTR has several bad propeties that can surprise you, and have bitten Tor as well. The reason I ask is that this makes your IV-generation more critical than, say, CBC, XTS, or other modes. If you have an IV collision, you'll leak some message bits. 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. 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. 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). CBC on the other hand causes a single ciphertext bitflip to scramble a block of cleartext (16 or 32 bytes for 128bit vs 256bit) in an unpredictable and key-dependent way. -- Mike Perry -- 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] Internet blackout
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
Re: [liberationtech] Cryptocat: Translation Volunteers Needed
On 11/06/2013 5:54 PM, Andy Isaacson wrote: The amount of work you're demanding (and yes, your first public post did come across as, arguably, demanding; and you doubled down when Nadim pushed back) I suggest you read my first email again. I did not demand anything. I asked why Opera was not supported. If someone had bothered to give me the reasons that you offered in your message instead of a) ignoring me, b) insulting me off-list, c) claiming that n% of users (roughly over 200 million) was not worth the trouble and/or d) telling me to just contribute code (as if everyone can just do that in the real world), this discussion would likely have gone very differently. I feel that this discussion has become quite off-topic and much too personal so I will not be commenting again on this subject. I am however available for discussions off-line, provided that they are respectful and constructive. Best regards, Catherine -- Catherine Roy http://www.catherine-roy.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
Re: [liberationtech] Cryptocat: Translation Volunteers Needed
I would sincerely like to apologize to the LibTech community for this incredibly embarrassing episode. NK On 2013-06-11, at 6:56 PM, Catherine Roy ecr...@catherine-roy.net wrote: On 11/06/2013 5:54 PM, Andy Isaacson wrote: The amount of work you're demanding (and yes, your first public post did come across as, arguably, demanding; and you doubled down when Nadim pushed back) I suggest you read my first email again. I did not demand anything. I asked why Opera was not supported. If someone had bothered to give me the reasons that you offered in your message instead of a) ignoring me, b) insulting me off-list, c) claiming that n% of users (roughly over 200 million) was not worth the trouble and/or d) telling me to just contribute code (as if everyone can just do that in the real world), this discussion would likely have gone very differently. I feel that this discussion has become quite off-topic and much too personal so I will not be commenting again on this subject. I am however available for discussions off-line, provided that they are respectful and constructive. Best regards, Catherine -- Catherine Roy http://www.catherine-roy.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 -- 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] Guardian reporter delayed e-mailing NSA source because crypto is a pain
This story really solidifies why I believe that we need to make privacy technologies accessible to journalists, instead of simply focusing on the other way around. Glenn Greenwald had to substantially delay his communications with Edward Snowden due to how inaccessible a lot of privacy and encryption software is to use. Our main and primary goal at Cryptocat has been to focus on making encrypted communications accessible, easier to use and fun and attractive. We've always believed that accessibility is a security feature, and this idea is at the core of our project. http://arstechnica.com/security/2013/06/guardian-reporter-delayed-e-mailing-nsa-source-because-crypto-is-a-pain/ 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
Re: [liberationtech] Guardian reporter delayed e-mailing NSA source because crypto is a pain
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 it's become a regular part of my workflow in discussing security critical bugs. I am a programmer and a computing expert. I do not consider the tools easy to use at all but I understand their importance and use them with other people who understand their importance, _in spite_ of the fact that they are burdensome. I am large unable to get people who do not understand their importance to use them. Or even if I get them to use them once, because the tools require an effort to use on an ongoing basis they do not use them reliably. The only shining ray of success I've experienced in this space is OTR, and but my personal experience is that even that is failing as more people move away from using pidgin and adium to chat systems which OTR does not as easily integrate with. -- 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
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 2013.06.11 17.44, Richard Brooks wrote: 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? Not Fidonet, because the world has moved on, but Briar is designed with a similar store-and-forward architecture as a delay-tolerant messaging system with strong security guarantees, intended to work across whatever transport is available in the moment for exactly this kind of situation. While we're a ways from being ready for use in any kind of high-risk (or even low-risk-but-real) scenario, we've got an early alpha out if you want to play with it. We're also looking for more help, especially from developers (Java; Android, Swing, JDBC, concurrency, etc.); we're happy to mentor less-experienced developers. More info here: http://briar.sourceforge.net/get-involved.html. /ad E. - -- Ideas are my favorite toys. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) iF4EAREIAAYFAlG3/sgACgkQQwkE2RkM0wpIyQD/d3gZhRQ7gfFOZwD5u5HnIK2H HUVDJgIkIltdL3EmNTwA/RUgVH0i9w6v+5AjuWxHukljXsJgUoI8YmhXPzjoRLdg =LOBj -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
