- cypherpunks - lists.cpunks.org

Re: [liberationtech] Open Whisper Systems' neat asynch FPS "pre-keying"
by Eugen Leitl 23 Aug '13

23 Aug '13

----- Forwarded message from Maxim Kammerer <mk(a)dee.su> ----- Date: Fri, 23 Aug 2013 00:43:11 +0300 From: Maxim Kammerer <mk(a)dee.su> To: liberationtech <liberationtech(a)lists.stanford.edu> Subject: Re: [liberationtech] Open Whisper Systems' neat asynch FPS "pre-keying" Reply-To: liberationtech <liberationtech(a)lists.stanford.edu> On Thu, Aug 22, 2013 at 9:03 PM, Joseph Lorenzo Hall <joe(a)cdt.org> wrote: > TextSecure’s upcoming iOS client (and Android data channel client) uses > a simple trick to provide asynchronous messaging while simultaneously > providing forward secrecy. Not sure if I understand all iOS-related issues described, but this seems like overcoming engineering problems with a synchronous protocol like OTR on iOS at the expense of exposing the clients to a DOS attack of exhausting the prekeys. However, an asynchronous protocol does not mean that all information must be delivered in one push. In cables communication [1], I chose simple asynchronous messages because I don't trust complex SSL handshakes or the cumbersome OTR protocol, and because I believe that reliable delivery receipts and resilience to DOS attacks are as important as the message itself. The exchange goes similar to the following (each line describes what is sent by sender (s) / receiver (r)) [2]: (s) peer request (r) certificate, signed peer key (s) certificate, signed peer key, encrypted message+MAC (r) receipt+MAC (s) acknowledgement+MAC and is similar to a state machine where each state is retried in sender / receiver until a new state is reached. The exchange above is somewhat implementation-specific for short requests followed by long fetches (implementation is HTTP-based and targeted for .onions), and for generic messages it can be reformulated as: (s) certificate, signed peer key (r) certificate, signed peer key (s) encrypted message+MAC (r) receipt+MAC (s) acknowledgement+MAC (In cables, username is certificate's fingerprint, so MITM'ing the certificate is not an issue.) So, with a centralized DB / prekeys I guess it's possible to shave off the first two messages, but does it really matter if the protocol is asynchronous to begin with? [1] http://dee.su/cables [2] https://github.com/mkdesu/cables/blob/master/doc/cable.txt -- Maxim Kammerer Liberté Linux: http://dee.su/liberte -- Liberationtech is a public list whose archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at companys(a)stanford.edu. ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5

1 0

Re: [liberationtech] Deterministic Builds Part One: Cyberwar and Global Compromise
by Eugen Leitl 23 Aug '13

23 Aug '13

----- Forwarded message from phreedom(a)yandex.ru ----- Date: Fri, 23 Aug 2013 00:21:25 +0300 From: phreedom(a)yandex.ru To: liberationtech <liberationtech(a)lists.stanford.edu> Subject: Re: [liberationtech] Deterministic Builds Part One: Cyberwar and Global Compromise User-Agent: KMail/4.10.5 (Linux/3.9.11; KDE/4.10.5; i686; ; ) Reply-To: liberationtech <liberationtech(a)lists.stanford.edu> > I think a lot of people would benefit from reading Mike Perry's latest > blog post. He addresses how The Tor Project is working towards the > problems referenced by Zooko in his latest open letter to Silent Circle: > "Current popular software development practices simply cannot survive > targeted attacks of the scale and scope that we are seeing today. " NixOS distro[1] takes build reproducibility seriously and build determinism is being worked on. I have patched the most important toolchains to not systematically introduce non-determinism[2]. Some of the patches are in the master branch already, some are in the staging branch and will be merged in a month or two. These patches are sufficient to make a large subset of package builds deterministic. After the merge, I'll do another round this time fixing non-determinism due to quirks of build systems of specific packages. Luckily, there aren't that many packages like Firefox and luckily Firefox has been already tackled by someone else :) I'm committed to making at least installation media, typical desktop and server installs fully deterministic. [1] http://nixos.org/nixos/ [2] http://lists.science.uu.nl/pipermail/nix-dev/2013-June/011357.html -- Liberationtech is a public list whose archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at companys(a)stanford.edu. ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5

1 0

[liberationtech] Open Whisper Systems' neat asynch FPS "pre-keying"
by Eugen Leitl 23 Aug '13

23 Aug '13

----- Forwarded message from Joseph Lorenzo Hall <joe(a)cdt.org> ----- Date: Thu, 22 Aug 2013 14:03:55 -0400 From: Joseph Lorenzo Hall <joe(a)cdt.org> To: liberationtech <liberationtech(a)lists.stanford.edu> Subject: [liberationtech] Open Whisper Systems' neat asynch FPS "pre-keying" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 Reply-To: liberationtech <liberationtech(a)lists.stanford.edu> https://whispersystems.org/blog/asynchronous-security/ ... The TextSecure Protocol TextSecure’s upcoming iOS client (and Android data channel client) uses a simple trick to provide asynchronous messaging while simultaneously providing forward secrecy. At registration time, the TextSecure client preemptively generates 100 signed key exchange messages and sends them to the server. We call these “prekeys.” A client that wishes to send a secure message to a user for the first time can now: 1. Connect to the server and request the destination’s next “prekey.” 2. Generate its own key exchange message half. 3. Calculate a shared secret with the prekey it received and its own key exchange half. 4. Use the shared secret to encrypt the message. 5. Package up the prekey id, the locally generated key exchange message, and the ciphertext. 6. Send it all in one bundle to the destination client. The user experience for the sender is ideal: they type a message, hit send, and an encrypted message is immediately sent. The destination client receives all of this as a single push notification. When the user taps it, the client has everything it needs to calculate the key exchange on its end, immediately decrypt the ciphertext, and display the message. With the initial key exchange out of the way, both parties can then continue communicating with an OTR-style protocol as usual. Since the server never hands out the same prekey twice (and the client would never accept the same prekey twice), we are able to provide forward secrecy in a fully asynchronous environment. -- Joseph Lorenzo Hall Senior Staff Technologist Center for Democracy & Technology 1634 I ST NW STE 1100 Washington DC 20006-4011 (p) 202-407-8825 (f) 202-637-0968 joe(a)cdt.org PGP: https://josephhall.org/gpg-key fingerprint: BE7E A889 7742 8773 301B 4FA1 C0E2 6D90 F257 77F8 -- Liberationtech is a public list whose archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at companys(a)stanford.edu. ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5

1 0

Encrypted mailing lists?
by Matej Kovacic 23 Aug '13

23 Aug '13

Hi, I would like to share some of my thoughts about encrypting mesages on mailing lists. I think that it would be really great if Mailman (and other mailing list applications) would support encryption. When user will register to mailing list he or she should send his/her public GPG key to the Mailman server. He/she would then receive public GPG key of mailing list. All mail sent to the list should then be encrypted (recipient is mailing list address and user has it's public GPG key). Mailing list would then decrypt it, and deliver that message to it's users encrypted and signed. That approach would resolve several problems: - user would know that messages are really coming from mailing list (no impersonation here); - no spam anymore (or at least much less spam) - registered users would need to send encrypted e-mails to mailing list, all other messages will be dropped; - messages are sent to user in encrypted form (regardless mail archive is public or not) - prevents eavesdropping on public places for instance; - messages stored in user's mailbox are encrypted (this could be important in some countries (don't forget bordercrossing!). Even if mailing list archive is public, this prevents automatic forensic tools to get useful information from the seized disks; - if mailing list is not public messages in an archive are really safe (remember quintessenz and NSA mailing list archive story? :-> ); - if mailing list is public messages in archive are still signed and their itegrity could be checked; - this would promote encryption in several ways: users would be "forced" to use encryption and users would get familiar with encryption; - and this is also important: more e-mail traffic would be encrypted by default - that makes all us who use encryption more safe. Remember: NSA thinks that everybody using encryption should automatically become a target od broader surveillance - let's overload them). I believe we should ask Mailman developers to include that functionality in the future releases. What do you think? Regards, Matej

11 13

Re: [Doctrinezero] HTTPS
by Eugen Leitl 23 Aug '13

23 Aug '13

----- Forwarded message from Bryce Lynch <bryce(a)zerostate.is> ----- Date: Thu, 22 Aug 2013 12:00:52 -0400 From: Bryce Lynch <bryce(a)zerostate.is> To: doctrinezero(a)zerostate.is Subject: Re: [Doctrinezero] HTTPS Organization: Zero State User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130514 Thunderbird/17.0.6 Reply-To: doctrinezero(a)zerostate.is -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/21/2013 10:37 AM, Dirk Bruere wrote: > Do the certification authorities hold a key that can break the > encryption of sites that use it? It's more complicated than that. Most of the time, whenever someone buys an SSL certificate pair signed by a CA, they have the CA generate the certificate pair for them (because OpenSSL's command line is pants, usually), sign it for them, and then send them the whole mess. The CA archives copies of the public and private certs after signing. We've seen several times in the past where CAs have given untrusted third parties copies of those signed certs. Ouch. There is a subtle flaw in the CA ecosystem: So long as a cert is signed by a CA that the client trusts, it doesn't matter /who/ the signer was. So, example.com could buy an SSL certificate from Thawte, and Eve could buy an SSL cert from Comodo for example.com. Eve could then use her cert for example.com to run a man-in-the-middle attack against users of example.com, and their browsers would never notice because both Thawte and Comodo are trusted. The SSL protocol has no provision for noticing if and when the trust chain changes in mid-flight. Double ouch. We've seen this one happen in the field several times. This is how ComodoHacker wrecked so much havoc a few years ago. There is another flaw in SSL: Wildcards. It is not uncommon for companies to buy SSL certs valid for *.example.com, so that they have only one cert covering all of their SSL enabled resources. What isn't obvious is that it's possible to generate a valid cert for *.com. Or *.org. Or *. Those certs are valid for *.com, or *.org, or * (any SSL enabled resource on the global Net) until they expire. A few of the big CAs sell these for whoever can pony up for them (they're very expensive) because they can be loaded into DPI/DCI hardware which basically carries out MITM attacks for detecting data exfiltration. That they are also used for surveillance comes with the territory. At least one CA that was pwned in the past five years had a number of wildcard certs generated by the attacker for * which are good until 1 January 2038. Uh-oh. Third parties have been trying to find ways to fix this - certificate pinning, TOFU/POP, Webs of Trust for SSL, Convergence, manually untrusting every CA in your browser - but none of them have caught on. - -- The Doctor [412/724/301/703] [ZS] PGP: 0xF1F922F2 / CABE 73FB 2D68 D1EF 3956 A468 7B1F DFE8 F1F9 22F2 WWW: https://drwho.virtadpt.net/ The future belongs to the brave. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJSFjWzAAoJEHsf3+jx+SLyYGUH/3ekahHofFHoxwcIAXikcxY6 SEgYQdN2MQyyX4JHfC+T56d0spWyBykd87NV53+qqxLkRpK90OHAgcciKTctyFw7 Vw4VUGIJlie+IXItZTD203mWLjfHlNubJFCTCFeujVs/Sl9WBCXOi3I2mN9RP20j G3EPYvR7NWUk8Y0O66ZUwh5Wnblj1PtbpCqU6vbByK1DWTIOopI1UC++aU7wYw4F 9IyfoXRe7JJIjexxq03XRsOc2GeaYkuy6LpwG+LDO3HrTv7Us7Y5plF/ybUnuQWL pccOHBcUgnvaCcD+8S8/6x0do8qVQNNVu74C88SCDR0R6vrNT0k2Ws1wfG8ix8s= =oa/z -----END PGP SIGNATURE----- _______________________________________________ Doctrinezero mailing list Doctrinezero(a)zerostate.is Unsubscribe: https://lists.zerostate.is/mailman/listinfo/doctrinezero ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5

3 2

Re: NSLs, gag-orders, code-changes, coerced backdoors - any tech response? (Re: Lavabit and End-point Security)
by John Young 22 Aug '13

22 Aug '13

One of the many salutory if unsavory aspects of cypherpunks is that a fresh proposal is more likely to be disagreed with than supported, rabid-dog disagreement cloaking theft and plagiarism. Rotters will then go off to get something done with stolen material, most will remain to shrewly pretend to demolish whatever "cluelessness" shows up, to asymmetrically burgle and secretize openness loot like official spies. Lacking cluelessness to taunt into full disclosure the bandits will brag of prowess, refer auto-didactly to misunderstood, unread sources (some fictional hidden by errant URLs), throw out poisoned baited code, cackle at the writhing suckers who bite the freebie and foolishly insert as covert backdoor, but never admit having been hooked repeatedly, instead pay ahead the pain of gullibility, lesson learned from distinguished computer professors and OS-backdoored Middle East negotiators. Does this remind of Assange among several ignotables who went off-list to reshape the world as "life-changing" endeavor? And who may or may not be among current hyenas here lying in wait for fresh carrion like Bell, CJ, Manning, Swartz, BBrown, Anonymous, Lulzsec, Sabu, Appelbaum, Gonggrijp, Jonsdottir, Snowden, Poitras, Greenwald, the list of vanity-incomsec-diseased ever lengthens. The dozen or so best and brightest will fail at their incomsec ventures, hoodwinked by better and brighter vultures preying on red meat wizards incompetent at asymmetrical financial math with dreams of lucrative public interest benefits fronted by sterling reputations. RSA, PGP, NSA venture-backdooring susceptible.

3 2

David and Glenn in Berlin
by Sylvia Ganush 22 Aug '13

22 Aug '13

After all, the UK were right to suspect David Miranda, Glenn Greenwald's honey, of terrorism. While in Berlin the pair infiltrated the President's innermost security perimiter. Look at this photo: http://www.flickr.com/photos/whitehouse/9314671291/lightbox/ David is checking out the Inspire magazine on his laptop, as Glenn is fixing wires to a pressure cooker. If this is not a terror plot, I don't know what is. Sylvia

8 10

Is the Wikileaks Party a cypherpunk party?
by CryptoFreak 21 Aug '13

21 Aug '13

While I'm American, I've been paying close attention to the Wikileaks Party in Australia. Could it be the political embodiment of the cypherpunk movement? Regardless of what some think of Julian Assange, he certainly holds true to the cp ethic and the parties belief in accountability, privacy, and justice, seem well aligned with the movement. So what do you think? Is their finally a political party more closely aligned with the cypherpunk ideal than the Libertarians? Regards, CryptoFreak

10 18

do we know who developed this website ?
by Cari Machet 21 Aug '13

21 Aug '13

https://www.wefightcensorship.org/online-survival-kithtml.html -- Cari Machet NYC 646-436-7795 carimachet(a)gmail.com AIM carismachet Skype carimachet - 646-652-6434 Syria +963-099 277 3243 Amman +962 077 636 9407 Berlin +49 152 11779219 Twitter: @carimachet <https://twitter.com/carimachet> Ruh-roh, this is now necessary: This email is intended only for the addressee(s) and may contain confidential information. If you are not the intended recipient, you are hereby notified that any use of this information, dissemination, distribution, or copying of this email without permission is strictly prohibited.

3 3

Freedom Hosting Owner Arrested, Tormail Compromised, Malicious JS Discovered
by Rich Jones 21 Aug '13

21 Aug '13

https://openwatch.net/i/200/anonymous-web-host-freedom-hosting-owner-arrest… Owner arrested in Ireland, FBI makes extradition request, malicious JavaScript discovered on a number of important hidden services. What happened?Eric Eoin Marques, the 28 year old owner and operator of the Tor-based internet host 'Freedom Hosting' has been arrested in Ireland and charged with distributing and promoting child pornography on the internet, reports<http://www.independent.ie/irish-news/courts/fbi-bids-to-extradite-largest-c…> the Independent. Since the arrest, internet users have reported<http://www.reddit.com/r/onions/comments/1jmrta/founder_of_the_freedom_hosti…> noticing malicious JavaScript <http://pastebin.com/pmGEj9bV> designed to compromise their identities inserted into pages hosted by Freedom Hosting, including the 'Tormail' service, as well as a number of pedophile messageboards. Why?'Freedom Hosting' provides hosting for anonymous 'hidden services' on the Tor network. These services can range from everything from anonymous email and library services, to online marketplaces for drug distribution and the production and exchange of child pornography. As this is part of an ongoing FBI investigation, there is no conclusive evidence that the injection of this JavaScript is the result of a government operation, however, this does fall under a known pattern of FBI behavior<http://gizmodo.com/why-the-fbi-ran-a-child-porn-site-for-two-whole-weeks-51…> related to child porn sting operations. It is possible that the attack, which delivers a weaponized exploit to Firefox users running Windows systems, is the work of non-government cyber criminals, although the timing of the arrest and the appearance of this code on a number of hidden services hosted by Freedom Hosting does seem to imply a government operation. The execution of malicious JavaScript inside the Tor Browser Bundle, perhaps the most commonly used Tor client, comes as a surprise to many users. Previously, the browser disabled JavaScript execution by default for security purposes, however this change was recently reverted by developers in order to make the product more useful for average internet users. As a result, however, the applications has become vastly more vulnerable to attacks such as this*. * What's going to happen next?Although it is difficult to gauge the size of the anonymous internet, Freedom Hosting did seem to be perhaps the largest anonymous web host, and its compromise will have serious implications for the future of Tor hidden services. We expect there will be a deeper technical analysis of the malware in the coming days as security researchers examine it in greater detail. Since the attack was designed at Firefox for Windows, which the Tor Browser Bundle is based upon, it seems likely that this is not a random occurance, and that the malware is designed specifically designed to compromise the identities of anonymous internet users. Although this would be a victory for the FBI against child pornographers who use the Tor network, it could also mean a serious security breach for international activists and internet users living in repressive states who use the services to practice online free speech. OpenWatch has been in the early stages of designing a new alternative to Freedom Hosting, calledOnionCloud <https://github.com/Miserlou/OnionCloud>, to allow anonymous Heroku-like application hosting. Developers interested in this idea and other OpenWatch technologies are invited to join the discussion by joining the openwatch-dev mailing list by sending an email to openwatch-dev+subscribe(a)googlegroups.com

10 13