- cypherpunks - lists.cpunks.org

Re: [liberationtech] iPhone5S Fingerprint and 5th amendment
by Eugen Leitl 11 Sep '13

11 Sep '13

----- Forwarded message from Joseph Lorenzo Hall <joe(a)cdt.org> ----- Date: Wed, 11 Sep 2013 13:27:42 -0400 From: Joseph Lorenzo Hall <joe(a)cdt.org> To: liberationtech <liberationtech(a)lists.stanford.edu> CC: Eugen Leitl <eugen(a)leitl.org> Subject: Re: [liberationtech] iPhone5S Fingerprint and 5th amendment User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 On 9/11/13 12:08 PM, Eugen Leitl wrote: > On Wed, Sep 11, 2013 at 11:04:44AM -0500, Matt Mackall wrote: > >> Similarly, any other sort of one-way algorithm that prevents you from >> reconstructing a valid input from the stored data is not going to work. > > Typical fingerprint matching uses classification, recognizing and > encoding multiple features into a vector. You could use a one-way > hash on that vector. This is likely subject to a precompiled hash > lookup table attack, as the number of all possible fingerprints, > quantized via a classification vector is not that large. There's a good deal of existing research out there on using symmeteric hashes -- a hash that can accept discrete inputs in arbitrary order and always calculate to the same value -- for secure biometric template storage and matching. Here is a paper I point people to that many of you will find absolutely fascinating (although it's been some years so do check citations pointing to this for further work): Sergey Tulyakov, Faisal Farooq, Praveer Mansukhani, & Venu Govindaraju. (2007). Symmetric hash functions for secure fingerprint biometric systems. Pattern Recognition Letters, 28(16), 2427–2436. Retrieved from http://www.researchgate.net/publication/222570842_Symmetric_hash_functions_… -- 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 ----- 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

Dual EC DRBG Memo
by Rich Jones 11 Sep '13

11 Sep '13

NYT confirming suspected Dual EC DRBG backdoor, citing leaked memo, but didn't include the PDF/PPT/mbox/nfo/whatever.. Does anybody have a copy? From http://bits.blogs.nytimes.com/2013/09/10/government-announces-steps-to-rest… But internal memos leaked by a former N.S.A. contractor, Edward Snowden, > suggest that the N.S.A. generated one of the random number generators used > in a 2006 N.I.S.T. standard — called the Dual EC DRBG standard<http://web.archive.org/web/20060930163233/http://csrc.nist.gov/publications…>— which contains a back door for the N.S.A. In publishing the standard, > N.I.S.T. acknowledged “contributions” from N.S.A., but not primary > authorship. > R

3 3

Re: [Cryptography] SPDZ, a practical protocol for Multi-Party Computation
by Eugen Leitl 11 Sep '13

11 Sep '13

----- Forwarded message from Max Kington <mkington(a)webhanger.com> ----- Date: Wed, 11 Sep 2013 18:14:42 +0100 From: Max Kington <mkington(a)webhanger.com> To: Eugen Leitl <eugen(a)leitl.org> Cc: cypherpunks(a)al-qaeda.net, cryptography(a)randombit.net, Cryptography List <cryptography(a)metzdowd.com> Subject: Re: [Cryptography] SPDZ, a practical protocol for Multi-Party Computation On 11 Sep 2013 18:01, "Eugen Leitl" <eugen(a)leitl.org> wrote: > > > http://www.mathbulletin.com/research/Breakthrough_in_cryptography_could_res… > > Breakthrough in cryptography could result in more secure computing > (9/10/2013) > > Tags: computer science, research, security, cryptography > > Nigel Smart, Professor of Cryptology > > New research to be presented at the 18th European Symposium on Research in > Computer Security (ESORICS 2013) this week could result in a sea change in > how to secure computations. > > The collaborative work between the University of Bristol and Aarhus > University (Denmark) will be presented by Bristol PhD student Peter Scholl > from the Department of Computer Science. > > The paper, entitled 'Practical covertly secure MPC for dishonest majority - > or: Breaking the SPDZ limits', builds upon earlier joint work between Bristol > and Aarhus and fills in the missing pieces of the jigsaw from the groups > prior work that was presented at the CRYPTO conference in Santa Barbara last > year. > > The SPDZ protocol (pronounced "Speedz") is a co-development between Bristol > and Aarhus and provides the fastest protocol known to implement a theoretical > idea called "Multi-Party Computation". > > The idea behind Multi-Party Computation is that it should enable two or more > people to compute any function of their choosing on their secret inputs, > without revealing their inputs to either party. One example is an election, > voters want their vote to be counted but they do not want their vote made > public. > > The protocol developed by the universities turns Multi-Party Computation from > a theoretical tool into a practical reality. Using the SPDZ protocol the team > can now compute complex functions in a secure manner, enabling possible > applications in the finance, drugs and chemical industries where computation > often needs to be performed on secret data. > > Nigel Smart, Professor of Cryptology in the University of Bristol's > Department of Computer Science and leader on the project, said: "We have > demonstrated our protocol to various groups and organisations across the > world, and everyone is impressed by how fast we can actually perform secure > computations. > > "Only a few years ago such a theoretical idea becoming reality was considered > Alice in Wonderland style over ambitious hope. However, we in Bristol > realised around five years ago that a number of advances in different areas > would enable the pipe dream to be achieved. It is great that we have been > able to demonstrate our foresight was correct." > > The University of Bristol is now starting to consider commercialising the > protocol via a company Dyadic Security Limited, co-founded by Professor Smart > and Professor Yehuda Lindell from Bar-Ilan University in Israel. A colleague is looking into this venture. I gave him a synopsis of their additions to SPDZ. There is a white paper describing their technology at their website which talks about the other two related protocols, Yao and Tiny-OT. One interesting use that occurred to me was the ability to split the two nodes in their implementation across jurisdictions. Especially those who are unlikely to ever collaborate. That giving you an advantage over a typical HSM which could live in a jurisdiction that could be seized. The wp and associated bibliography is available at http://www.dyadicsec.com/SiteAssets/resources1/DyadicWhitePaper.pdf Max > > Note: This story has been adapted from a news release issued by the > University of Bristol > > _______________________________________________ > The cryptography mailing list > cryptography(a)metzdowd.com > http://www.metzdowd.com/mailman/listinfo/cryptography ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5

1 0

[Cryptography] Defenses against pervasive versus targeted intercept
by Eugen Leitl 11 Sep '13

11 Sep '13

----- Forwarded message from Phillip Hallam-Baker <hallam(a)gmail.com> ----- Date: Wed, 11 Sep 2013 12:11:52 -0400 From: Phillip Hallam-Baker <hallam(a)gmail.com> To: "cryptography(a)metzdowd.com" <cryptography(a)metzdowd.com> Subject: [Cryptography] Defenses against pervasive versus targeted intercept I have spent most of yesterday writing up much of the traffic on the list so far in the form of an Internet Draft. I am now at the section on controls and it occurs to me that the controls relevant to preventing PRISM-like pervasive intercept capabilities are not necessarily restricted to controls that protect against targeted intercept. The problem I have with PRISM is that it is a group of people whose politics I probably find repellent performing a dragnet search that may later be used for McCarthyite/Hooverite inquisitions. So I am much more concerned about the pervasive part than the ability to perform targeted attacks on a few individuals who have come to notice. If the NSA wanted my help intercepting Al Zawahiri's private emails then sign me up. My problem is that they are intercepting far too much an lying about what they are doing. Let us imagine for the sake of argument that the NSA has cracked 1024 bit RSA using some behemoth computer at a cost of roughly $1 million per key and taking a day to do so. Given such a capability it would be logical for them to attack high traffic/high priority 1024 bit keys. I have not looked into the dates when the 2048 bit roll out began (seems to me we have been talking about it ten years) but that might be consistent with that 2010 date. If people are using plain TLS without perfect forward secrecy, that crack gives the NSA access to potentially millions of messages an hour. If the web browsers are all using PFS then the best they can do is one message a day. PFS provides security even when the public keys used in the conversation are compromised before the conversation takes place. It does not prevent attack but it reduces the capacity of the attacker. Similar arguments can be made for other less-than-perfect key exchange schemes. It is not necessary for a key exchange scheme to be absolutely secure against all possible attack for it to be considered PRISM-Proof. So the key distribution scheme I am looking at does have potential points of compromise because I want it to be something millions could use rather than just a few thousand geeks who will install but never use. But the objective is to make those points of compromise uneconomic to exploit on the scale of PRISM. The NSA should have accepted court oversight of their activities. If they had strictly limited their use of the cryptanalytic capabilities then the existence would not have been known to low level grunts like Snowden and we probably would not have found out. Use of techniques like PFS restores balance. -- Website: http://hallambaker.com/ _______________________________________________ The cryptography mailing list cryptography(a)metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5

1 0

Re: [guardian-dev] pgp, nsa, rsa
by Eugen Leitl 11 Sep '13

11 Sep '13

----- Forwarded message from Billy Gray <wgray(a)zetetic.net> ----- Date: Tue, 10 Sep 2013 14:32:02 -0400 From: Billy Gray <wgray(a)zetetic.net> To: Aaron Lux <a(a)aaronlux.com> Cc: Guardian Dev <guardian-dev(a)lists.mayfirst.org> Subject: Re: [guardian-dev] pgp, nsa, rsa Do you guys follow Matthew Green? Great stuff: http://blog.cryptographyengineering.com/2013/09/on-nsa.html http://blog.cryptographyengineering.com/2013/09/a-note-on-nsa-future-and-fi… I think he does a good job of breaking down what's in these recent reports. It's a good thing to send to people who read the NY Times report and think that all crypto is now broken (like a friend of mine asked me at NWC yesterday). And then there was this: http://www.theguardian.com/commentisfree/2013/sep/10/nsa-matthew-green-take… One more question: any of y'all used libTomCrypt? We have an experimental implementation of it in SQLCipher. Open-source alternatives to OpenSSL could use some love. DJB's NaCl is neat, too. Curious if you guys are leery of relying so heavily on OpenSSL, given the above. http://libtom.org/?page=features&newsitems=5&whatfile=crypt http://nacl.cr.yp.to Cheers, Billy On Tue, Sep 10, 2013 at 11:17 AM, Aaron Lux <a(a)aaronlux.com> wrote: > NSA’s mission includes deciphering enciphered communications is not a > secret, and is not news*. I am concerned the nytimes.com article will > have the effect of causing the public to lose trust in all encryption > including open-source algorithms. Hopefully people realize reviewing > source code for encryption algorithms** is much more relaxing than > reading the NY Times. > > > * nsa.gov states that its mission includes leading “the U.S. Government > in cryptology … in order to gain a decision advantage for the Nation and > our allies.” > > ** ftp://ftp.gnupg.org/gcrypt/gnupg/gnupg-2.0.21.tar.bz2 and > > http://mirror.team-cymru.org/pub/OpenBSD/OpenSSH/portable/openssh-6.2p2.tar… > > > Look at the top and bottom of every page: TOP SECRET//SI//TK//NO FORN. > > This is a secret document. > > > > Cheers, > > Michael > > _______________________________________________ > Guardian-dev mailing list > > Post: Guardian-dev(a)lists.mayfirst.org > List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev > > To Unsubscribe > Send email to: Guardian-dev-unsubscribe(a)lists.mayfirst.org > Or visit: > https://lists.mayfirst.org/mailman/options/guardian-dev/wgray%40zetetic.net > > You are subscribed as: wgray(a)zetetic.net > -- Team Zetetic http://zetetic.net _______________________________________________ Guardian-dev mailing list Post: Guardian-dev(a)lists.mayfirst.org List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev To Unsubscribe Send email to: Guardian-dev-unsubscribe(a)lists.mayfirst.org Or visit: https://lists.mayfirst.org/mailman/options/guardian-dev/eugen%40leitl.org You are subscribed as: eugen(a)leitl.org ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5

3 2

[tor-talk] Tor Weekly News — September, 11th 2013
by Eugen Leitl 11 Sep '13

11 Sep '13

----- Forwarded message from Lunar <lunar(a)torproject.org> ----- Date: Wed, 11 Sep 2013 17:21:30 +0200 From: Lunar <lunar(a)torproject.org> To: tor-news(a)lists.torproject.org, tor-talk(a)lists.torproject.org Subject: [tor-talk] Tor Weekly News — September, 11th 2013 User-Agent: Mutt/1.5.21 (2010-09-15) Reply-To: tor-talk(a)lists.torproject.org ======================================================================== Tor Weekly News September 11th, 2013 ======================================================================== Welcome to the eleventh issue of Tor Weekly News, the weekly newsletter that covers what is happening in the taut Tor community. tor 0.2.4.17-rc is out ---------------------- There are now confirmations [1] that the sudden influx of Tor clients which started mid-August [2] is indeed coming from a botnet. “I guess all that work we’ve been doing on scalability was a good idea,” wrote Roger Dingledine in a blog post about “how to handle millions of new Tor clients” [3]. On September 5th, Roger Dingledine announced the release of the third release candidate for the tor 0.2.4 series [4]. This is an emergency release “to help us tolerate the massive influx of users: 0.2.4 clients using the new (faster and safer) ‘NTor’ circuit-level handshakes now effectively jump the queue compared to the 0.2.3 clients using ‘TAP’ handshakes” [5]. It also contains several minor bugfixes and some new status messages for better monitoring of the current situation. Roger asked relay operators to upgrade to 0.2.4.17-rc [6]: “the more relays that upgrade to 0.2.4.17-rc, the more stable and fast Tor will be for 0.2.4 users, despite the huge circuit overload that the network is seeing.” For relays running Debian or Ubuntu, upgrading to the development branch can be done using the Tor project’s package repository [7]. New versions of the beta branch of the Tor Browser Bundle are also available [8] since September 6th. The next Tails release, scheduled for September 19th [9] will also contain tor 0.2.4.17-rc [10]. Hopefully, this will be the last release candidate. What looks missing at this point to declare the 0.2.4.x series stable is simply enough time to finish the release notes. [1] http://blog.fox-it.com/2013/09/05/large-botnet-cause-of-recent-tor-network-… [2] https://lists.torproject.org/pipermail/tor-talk/2013-September/029822.html [3] https://blog.torproject.org/blog/how-to-handle-millions-new-tor-clients [4] https://lists.torproject.org/pipermail/tor-talk/2013-September/029857.html [5] https://bugs.torproject.org/9574 [6] https://lists.torproject.org/pipermail/tor-relays/2013-September/002701.html [7] https://www.torproject.org/docs/debian.html.en#development [8] https://blog.torproject.org/blog/new-tor-02417-rc-packages [9] https://mailman.boum.org/pipermail/tails-dev/2013-September/003622.html [10] https://mailman.boum.org/pipermail/tails-dev/2013-September/003621.html The future of Tor cryptography ------------------------------ After the last round of revelations from Edward Snowden, described as “explosive” by Bruce Schneier [11], several threads started on the tor-talk mailing list to discuss Tor cryptography. A lot of what has been written is speculative at this point. But some have raised concerns [12] about 1024 bit Diffie–Hellman key exchange [13]. This has already been addressed with the introduction of the “ntor” handshake [14] in 0.2.4 and Nick Mathewson encourages everybody to upgrade [15]. Another thread [16] prompted Nick to summarize [17] his views on the future of Tor cryptography. Regarding public keys, “with Tor 0.2.4, forward secrecy uses 256-bit ECC, which is certainly better, but RSA-1024 is still used in some places for signatures. I want to fix all that in 0.2.5 — see proposal 220 [18], and George Kadianakis’ draft hidden service improvements [19,20], and so forth.” Regarding symmetric keys, Nick wrote: “We’re using AES128. I’m hoping to move to XSalsa20 or something like it.” In response to a query, Nick clarifies that he doesn’t think AES is broken: only hard to implement right, and only provided in TLS in concert with modes that are somewhat (GCM) or fairly (CBC) problematic. The effort to design better cryptography for the Tor protocols is not new. More than a year ago, Nick Mathewson presented proposal 202 [21] outlining two possible new relay encryption protocols for Tor cells. Nick mentioned that he’s waiting for a promising paper to get finished here before implementation. A third question was raised [22] regarding the trust in algorithms certified by the US NIST [23]. Nick’s speculations put aside, he also emphasized that several NIST algorithms were “hard to implement correctly” [24]. Nick also plans to change more algorithms [25]: “Over the 0.2.5 series, I want to move even more things (including hidden services) to curve25519 and its allies for public key crypto. I also want to add more hard-to-implement-wrong protocols to our mix: Salsa20 is looking like a much better choice to me than AES nowadays, for instance.” Nick concluded one of his emails with the words: “these are interesting times for crypto”, which sounds like a good way to put it. [11] https://www.schneier.com/blog/archives/2013/09/the_nsa_is_brea.html [12] https://lists.torproject.org/pipermail/tor-talk/2013-September/029917.html [13] https://en.wikipedia.org/wiki/Diffie–Hellman_key_exchange [14] https://gitweb.torproject.org/torspec.git/blob_plain/HEAD:/proposals/216-nt… [15] https://lists.torproject.org/pipermail/tor-talk/2013-September/029930.html [16] https://lists.torproject.org/pipermail/tor-talk/2013-September/029927.html [17] https://lists.torproject.org/pipermail/tor-talk/2013-September/029941.html [18] https://gitweb.torproject.org/torspec.git/blob_plain/HEAD:/proposals/220-ec… [19] https://lists.torproject.org/pipermail/tor-dev/2013-August/005279.html [20] https://lists.torproject.org/pipermail/tor-dev/2013-August/005280.html [21] https://gitweb.torproject.org/torspec.git/blob_plain/HEAD:/proposals/202-im… [22] https://lists.torproject.org/pipermail/tor-talk/2013-September/029933.html [23] https://en.wikipedia.org/wiki/National_Institute_of_Standards_and_Technology [24] https://lists.torproject.org/pipermail/tor-talk/2013-September/029937.html [25] https://lists.torproject.org/pipermail/tor-talk/2013-September/029929.html Toward a better performance measurement tool -------------------------------------------- “I just finished […] sketching out the requirements and a software design for a new Torperf implementation“ announced Karsten Loesing [26] on the tor-dev mailing list. The report begins with: “Four years ago, we presented a simple tool to measure performance of the Tor network. This tool, called Torperf, requests static files of three different sizes over the Tor network and logs timestamps of various request substeps. These data turned out to be quite useful to observe user-perceived network performance over time [27]. However, static file downloads are not the typical use case of a user browsing the web using Tor, so absolute numbers are not very meaningful. Also, Torperf consists of a bunch of shell scripts which makes it neither very user-friendly to set up and run, nor extensible to cover new use cases.” The specification lays out the various requirements for the new tool, and details several experiments like visiting high profile websites with an automated graphical web browser, downloading static files, crafting a canonical web page, measuring hidden service performance, and checking on upload capacity. Karsten added “neither the requirements nor the software design are set in stone, and the implementation, well, does not exist yet. Plenty of options for giving feedback and helping out, and most parts don’t even require specific experience with hacking on Tor. Just in case somebody’s looking for an introductory Tor project to hack on.” Saytha already wrote that this was enough material to get the implementation started [28]. The project needs enough work that anyone interested should get involved. Feel free to join him! [26] https://lists.torproject.org/pipermail/tor-dev/2013-September/005386.html [27] https://metrics.torproject.org/performance.html [28] https://lists.torproject.org/pipermail/tor-dev/2013-September/005388.html More monthly status reports for August 2013 ------------------------------------------- The wave of regular monthly reports from Tor project members continued this week with Sukhbir Singh [29], Matt Pagan [30], Ximin Luo [31], mrphs [32], Pearl Crescent [33], Andrew Lewman [34], Mike Perry [35], Kelley Misata [36], Nick Mathewson [37], Jason Tsai [38], Tails [39], Aaron [40], and Damian Johnson [41]. [29] https://lists.torproject.org/pipermail/tor-reports/2013-September/000326.ht… [30] https://lists.torproject.org/pipermail/tor-reports/2013-September/000327.ht… [31] https://lists.torproject.org/pipermail/tor-reports/2013-September/000328.ht… [32] https://lists.torproject.org/pipermail/tor-reports/2013-September/000329.ht… [33] https://lists.torproject.org/pipermail/tor-reports/2013-September/000330.ht… [34] https://lists.torproject.org/pipermail/tor-reports/2013-September/000331.ht… [35] https://lists.torproject.org/pipermail/tor-reports/2013-September/000332.ht… [36] https://lists.torproject.org/pipermail/tor-reports/2013-September/000333.ht… [37] https://lists.torproject.org/pipermail/tor-reports/2013-September/000334.ht… [38] https://lists.torproject.org/pipermail/tor-reports/2013-September/000335.ht… [39] https://lists.torproject.org/pipermail/tor-reports/2013-September/000336.ht… [40] https://lists.torproject.org/pipermail/tor-reports/2013-September/000337.ht… [41] https://lists.torproject.org/pipermail/tor-reports/2013-September/000338.ht… Miscellaneous news ------------------ Not all new Tor users are computer programs! According to their latest report [42], Tails is now booted twice as much as it was six months ago (from 100,865 to 190,521 connections to the security feed). [42] https://lists.torproject.org/pipermail/tor-reports/2013-September/000336.ht… Thanks to Frenn vun der Enn [43] for setting up a new mirror [44] of the Tor project website. [43] http://enn.lu/ [44] https://lists.torproject.org/pipermail/tor-mirrors/2013-September/000351.ht… With the Google Summer of Code ending in two weeks, the students have sent their penultimate reports: Kostas Jakeliunas for the Searchable metrics archive [45], Johannes Fürmann for EvilGenius [46], Hareesan for the Steganography Browser Extension [47], and Cristian-Matei Toader for Tor capabilities [48]. [45] https://lists.torproject.org/pipermail/tor-dev/2013-September/005380.html [46] https://lists.torproject.org/pipermail/tor-dev/2013-September/005394.html [47] https://lists.torproject.org/pipermail/tor-dev/2013-September/005409.html [48] https://lists.torproject.org/pipermail/tor-dev/2013-September/005412.html Damian Johnson announced [49] that he had completed the rewrite of DocTor in Python [50], “a service that pulls hourly consensus information and checks it for a host of issues (directory authority outages, expiring certificates, etc). In the case of a problem it notifies tor-consensus-health@ [51], and we in turn give the authority operator a heads up.” [49] https://lists.torproject.org/pipermail/tor-reports/2013-September/000338.ht… [50] https://gitweb.torproject.org/doctor.git [51] https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-consensus-health Matt Pagan has migrated [52] several Frequently-Asked Questions from the wiki to the official Tor website [53]. This should enable more users to find the answers they need! [52] https://svn.torproject.org/cgi-bin/viewvc.cgi/Tor?view=revision&revision=26… [53] https://www.torproject.org/docs/faq.html In his previous call for help to collect more statistics [54], addressed to bridge operators, George Kadianakis forgot to mention that an extra line with “ExtORPort 6669” needed to be added to the tor configuration file [55]. Make sure you do have it if you are running a bridge on the tor master branch. [54] https://lists.torproject.org/pipermail/tor-relays/2013-August/002477.html [55] https://lists.torproject.org/pipermail/tor-relays/2013-September/002691.html For the upgrade of tor to the 0.2.4.x series in Tails, a tester spotted a regression while “playing with an ISO built from experimental, thanks to our Jenkins autobuilder” [56]. This marks a significant milestone in the work on automated builds [57] done by several members of the Tails team in the course of the last year! [56] https://mailman.boum.org/pipermail/tails-dev/2013-September/003617.html [57] https://labs.riseup.net/code/issues/5324 Tails’ next “low-hanging fruit” session will be on September 21st at 08:00 UTC [58]. Mark the date if you want to get involved! [58] https://mailman.boum.org/pipermail/tails-dev/2013-September/003566.html David Fifield gave some tips on how to setup a test infrastructure [59] for flash proxy [60]. [59] https://lists.torproject.org/pipermail/tor-dev/2013-September/005402.html [60] https://crypto.stanford.edu/flashproxy/ Marek Majkowski reported [61] on how one can use his fluxcapacitor tool [62] to get a test Tor network started with Chutney [63] ready in only 6.5 seconds. A vast improvement over the 5 minutes he initially had to wait [64]! [61] https://lists.torproject.org/pipermail/tor-dev/2013-September/005403.html [62] https://github.com/majek/fluxcapacitor.git [63] https://gitweb.torproject.org/chutney.git [64] https://lists.torproject.org/pipermail/tor-dev/2013-September/005413.html Eugen Leitl drew attention [65] to a new research paper which aims to analyze the content and popularity of Hidden Services by Alex Biryukov, Ivan Pustogarov, and Ralf-Philipp Weinmann from the University of Luxembourg [66]. [65] https://lists.torproject.org/pipermail/tor-talk/2013-September/029856.html [66] http://cryptome.org/2013/09/tor-analysis-hidden-services.pdf Tor Help Desk roundup --------------------- The Tor help desk had a number of emails this week asking about the recent stories in the New York Times, the Guardian, and ProPublica regarding NSA’s cryptographic capabilities. Some users asked whether there was a backdoor in Tor. Others asked if Tor’s crypto was broken. There is absolutely no backdoor in Tor. Tor project members have been vocal in the past about how tremendously irresponsible it would be to backdoor our users [67]. As it is a frequently-asked question, users have been encouraged to read how the project would respond to institutional pressure [68]. The Tor project does not have any more facts about NSA’s cryptanalysis capabilities than what has been published in newspapers. Even if there is no actual evidence that Tor encryption is actually broken, the idea is to remain on the safe side by using more trusted algorithms for the Tor protocols. See above for a more detailed write-up. [67] https://blog.torproject.org/blog/calea-2-and-tor [68] http://www.torproject.org/docs/faq.html.en#Backdoor Help the Tor community! ----------------------- Tor is about protecting everyone’s freedom and privacy. There are many ways to help [69] but getting involved in such a busy community can be daunting. Here’s a selection of tasks on which one could get started: Get tor to log the source of control port connections [70]. It would help in developing controller applications or libraries (like Stem [71]) to know which program is responsible for a given access to the control facilities of the tor daemon. Knowledge required: C programming, basic understanding of network sockets. Diagnose what is currently wrong with Tor Cloud images [72]. Tor Cloud [73] is an easy way to deploy bridges and it looks like the automatic upgrade procedure caused problems. Let’s make these virtual machines useful again for censored users. Knowledge required: basic understanding of Ubuntu system administration. [69] https://www.torproject.org/getinvolved/volunteer.html.en [70] https://bugs.torproject.org/9698 [71] https://stem.torproject.org/ [72] https://lists.torproject.org/pipermail/tor-dev/2013-September/005417.html [73] https://cloud.torproject.org/ Upcoming events --------------- Sep 29 | Colin at the Winnipeg Cryptoparty | Winnipeg, Manitoba, Canada | http://wiki.skullspace.ca/index.php/CryptoParty | Sep 29-01 | Tor at OpenITP Circumvention Tech Summit IV | Berlin, Germany | https://www.openitp.org/openitp/circumvention-tech-summit.html | Oct 09-10 | Andrew speaking at Secure Poland 2013 | Warszawa, Poland | http://www.secure.edu.pl/ This issue of Tor Weekly News has been assembled by Lunar, dope457, mttp, malaparte, harmony, Karsten Loesing, and Nick Mathewson. Want to continue reading TWN? Please help us create this newsletter. We still need more volunteers to watch the Tor community and report important news. Please see the project page [74], write down your name and subscribe to the team mailing list [75] if you want to get involved! [74] https://trac.torproject.org/projects/tor/wiki/TorWeeklyNews [75] https://lists.torproject.org/cgi-bin/mailman/listinfo/news-team -- tor-talk mailing list - tor-talk(a)lists.torproject.org To unsusbscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk ----- 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

hardware RNG
by Juan Garofalo 11 Sep '13

11 Sep '13

very naive question here : Wouldn't it be possible to build a RNG using something like a zener diode and a $2 microcontroller? J.

8 8

NIST reopens RNG public comment period
by Eugen Leitl 11 Sep '13

11 Sep '13

http://csrc.nist.gov/publications/PubsDrafts.html Sep. 9, 2013 SP 800-90 A Rev 1 B and C DRAFT Draft SP 800-90 Series: Random Bit Generators 800-90 A Rev. 1: Recommendation for Random Number Generation Using Deterministic Random Bit Generators 800-90 B: Recommendation for the Entropy Sources Used for Random Bit Generation 800-90 C: Recommendation for Random Bit Generator (RBG) Constructions In light of recent reports, NIST is reopening the public comment period for Special Publication 800-90A and draft Special Publications 800-90B and 800-90C. NIST is interested in public review and comment to ensure that the recommendations are accurate and provide the strongest cryptographic recommendations possible. The public comments will close on November 6, 2013. Comments should be sent to RBG_Comments(a)nist.gov. In addition, the Computer Security Division has released a supplemental ITL Security Bulletin titled "NIST Opens Draft Special Publication 800-90A, Recommendation for Random Number Generation Using Deterministic Random Bit Generators, For Review and Comment (Supplemental ITL Bulletin for September 2013)" to support the draft revision effort. Draft SP 800-90 A Rev. 1 (721 KB) Draft SP 800-90 B (800 KB) Draft SP 800-90 C (1.1 MB)

1 0

Re: [liberationtech] iPhone 5S Fingerprint and Records (Was: iPhone5S and 5th amendment)
by Eugen Leitl 11 Sep '13

11 Sep '13

----- Forwarded message from Andy Isaacson <adi(a)hexapodia.org> ----- Date: Tue, 10 Sep 2013 16:37:36 -0700 From: Andy Isaacson <adi(a)hexapodia.org> To: liberationtech <liberationtech(a)lists.stanford.edu> Subject: Re: [liberationtech] iPhone 5S Fingerprint and Records (Was: iPhone5S and 5th amendment) User-Agent: Mutt/1.5.20 (2009-06-14) Reply-To: liberationtech <liberationtech(a)lists.stanford.edu> On Tue, Sep 10, 2013 at 05:54:44PM -0400, Scott Elcomb wrote: > Starting a new thread - it's related but a slightly different topic. > > Despite having several devices with fingerprint scanners, I've never used one. > > With the release of iPhone 5S and all the discussion around it, I'm > curious if fingerprints on file with various Law Enforcement agencies > could be printed out or otherwise used to unlock devices detained at > border crossings or during other investigations? Printing a fingerprint is pretty easy: http://dasalte.ccc.de/biometrie/fingerabdruck_kopieren?language=en No word yet if this technique works on the iPhone reader. -andy -- 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

[Cryptography] EFF press release on latest FISA opinions release
by Eugen Leitl 11 Sep '13

11 Sep '13

----- Forwarded message from "Perry E. Metzger" <perry(a)piermont.com> ----- Date: Tue, 10 Sep 2013 19:12:32 -0400 From: "Perry E. Metzger" <perry(a)piermont.com> To: cryptography(a)metzdowd.com Subject: [Cryptography] EFF press release on latest FISA opinions release X-Mailer: Claws Mail 3.9.0 (GTK+ 2.24.20; x86_64-apple-darwin12.4.0) The documents haven't yet been completely processed, but they've already found some interesting features. Quoting: The NSA apparently believed that it had the authority to search the telephone records database in order to obtain the 'reasonable articulable suspicion' required to investigate those numbers. Essentially, they were conducting suspicionless searches to obtain the suspicion the FISA court required to conduct searches. https://www.eff.org/deeplinks/2013/09/government-releases-nsa-surveillance-… Note that the USG has misleadingly claimed that this document release was part of an effort to be "transparent" -- in fact, these are the result of an EFF FOIA and were released at court order. -- Perry E. Metzger perry(a)piermont.com _______________________________________________ The cryptography mailing list cryptography(a)metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5

1 0