- cypherpunks - lists.cpunks.org

[tor-talk] Tor Weekly News — October 23th, 2013
by Lunar 23 Oct '13

23 Oct '13

======================================================================== Tor Weekly News October 23th, 2013 ======================================================================== Welcome to the seventeenth issue of Tor Weekly News, the weekly newsletter that covers what is happening in the guarding Tor community. Tor’s anonymity and guards parameters ------------------------------------- In a lengthly blog post [1], Roger Dingledine looked back on three research papers published in the past year. Some of them have been covered and most of the time misunderstood by the press. A good recap of the research problems, what the findings mean and possible solutions hopefully will help everyone understand better. Introduced in 2005 [2], entry guards were added to recognise that “some circuits are going to be compromised, but it’s better to increase your probability of having no compromised circuits at the expense of also increasing the proportion of your circuits that will be compromised if any of them are.” Roger “originally picked ‘one or two months’ for guard rotation” but the initial parameters called for more in-depth research [3]. That call was heard by “the Tor research community [4], and it’s great that Tor gets such attention. We get this attention because we put so much effort into making it easy [5] for researchers to analyze Tor.” In his writing Roger highlights the finding of three papers. Two of them published at WPES 2012 and Oakland 2013, and another upcoming at CCS 2013. These research efforts highlighted several issues in the way Tor handles entry guards. Roger details five complementary fixes: using fewer guards, keeping the same guards for longer, better handling of brief unreachability of a guard, making the network bigger, and smarter assignment of the guard flag to relays. Some will require further research to identify the best solution. There are also other aspects regarding systems which don’t currently record guards such as Tails, how pluggable transports could prevent attackers from recognising Tor users, or enhancing measurements from the bandwidth authorities… The whole blog post is insightful and is a must read for everyone who wishes to better understand some of Tor’s risk mitigation strategies. It is also full of little and big things where you could make a difference! [1] https://blog.torproject.org/blog/improving-tors-anonymity-changing-guard-pa… [2] https://blog.torproject.org/blog/top-changes-tor-2004-design-paper-part-2 [3] https://blog.torproject.org/blog/research-problem-better-guard-rotation-par… [4] http://freehaven.net/anonbib/ [5] https://research.torproject.org/ Hidden Service research ----------------------- George Kadianakis posted a list of items that need work in the Hidden Service area [6]. Despite not being exhaustive, the list contains many items that might help with upgrading the Hidden Service design, be it around security, performance, guard issues or “petname” systems. Help and comments are welcome! [6] https://lists.torproject.org/pipermail/tor-dev/2013-October/005637.html Usability issues in existing OTR clients ---------------------------------------- The consensus after the first round of discussions and research done in the prospect of providing a new secure instant-messaging Tor bundle [7] is to use Mozilla Instantbird at its core. Arlo Breault sent out a draft plan [8] on how to do so. Instantbird currently lacks a core feature to turn it into the Tor Messenger: support for the OTR [9] protocol for encrypted chat. Now is thus a good time to gather usability issues in existing OTR clients. Mike Perry kicked off the discussion [10] by pointing out several deficiencies regarding problems with multiple clients, key management issues, and other sub-optimal behaviour. Ian Goldberg — original author of the pervasive OTR plugin for Pidgin — pointed out [11] that at least one of the behaviour singled out by Mike was “done on purpose. The thing it’s trying to prevent is that Alice and Bob are chatting, and Bob ends OTR just before Alice hits Enter on her message. If Alice’s client went to ‘Not private’ instead of ‘Finished’, Alice’s message would be sent in the clear, which is undesirable. Switching to ‘Finished’ makes Alice have to actively acknowledge that the conversation is no longer secure.” This tradeoff is a good example of how designing usable and secure user interfaces can be hard. Usability, in itself, is an often overlooked security feature. Now is a good time to contribute your ideas! [7] https://trac.torproject.org/projects/tor/wiki/org/sponsors/Otter/Attentive [8] https://lists.torproject.org/pipermail/tor-dev/2013-October/005616.html [9] https://otr.cypherpunks.ca/ [10] https://lists.torproject.org/pipermail/tor-dev/2013-October/005636.html [11] https://lists.torproject.org/pipermail/tor-dev/2013-October/005640.html Tor Help Desk Roundup --------------------- The Tor Help Desk continues to be bombarded with help requests from users behind university proxies who cannot use ORPort bridges or the Pluggable Transports Browser to circumvent their network’s firewall. Although the cases are not all the same, bridges on port 443 or port 80 do not always suffice to circumvent such proxies. Ubuntu 13.10 (Saucy Salamander) was released this week. One user reported their Tor Browser Bundle behaving unusually after updating their Ubuntu operating system. This issue was resolved by switching to the Tor Browser Bundle 3. Another user asked when Tor APT repositories would have packages for Saucy Salamander. Since then, packages for the latest version of Ubuntu have been made available from the usual deb.torproject.org. Miscellaneous news ------------------ Tails has issued a call for testing [12] of its upcoming 0.21 release. The new version contains two security fixes regarding access to the Tor control port and persistent settings [13] among other improvements and package updates [14]. “Test wildly!” as the Tails team wrote. [12] https://tails.boum.org/news/test_0.21-rc1/ [13] https://git-tails.immerda.ch/tails/plain/wiki/src/doc/first_steps/persisten… [14] https://git-tails.immerda.ch/tails/plain/debian/changelog?id=0.21-rc1 Andrew Lewman was invited to speak at SECURE Poland 2013 [15] and sent a report on his trip [16] to Warsaw. [15] http://www.secure.edu.pl/ [16] https://lists.torproject.org/pipermail/tor-reports/2013-October/000364.html Tails developers are looking for Mac and PC hardware with UEFI [17]. If you have some spare hardware, please consider a donation! [17] https://tails.boum.org/news/Mac_and_PC_UEFI_hardware_needed/ Ximin Luo has been the first to create a ticket with 5 digits [18] on Tor tracker. At the current rate, ticket #20000 should happen by the end of 2015… Or will the project’s continued growth make this happen sooner? [18] https://bugs.torproject.org/10000 Roger Dingledine reported [19] on his activities for September and October. Arturo Filastò also reported [20] on his September. [19] https://lists.torproject.org/pipermail/tor-reports/2013-October/000365.html [20] https://lists.torproject.org/pipermail/tor-reports/2013-October/000366.html Runa Sandvik continues her work on the new, more comprehensible Tor User Manual [21]. The first draft is already out [22]. Please review and contribute. [21] https://lists.torproject.org/pipermail/tor-dev/2013-October/005649.html [22] https://bugs.torproject.org/5811 Aaron published a branch with his work on a Tor exit scanner based on OONI [23]. [23] https://github.com/TheTorProject/ooni-probe/tree/feature/tor_test_template Upcoming events --------------- Oct 25 | Matt @ EPIC and Public Citizen’s CryptoParty | Washington, DC, USA | https://epic.org/events/cryptoparty/ | Nov 04 | Workshop on Privacy in the Electronic Society | Berlin, Germany | http://wpes2013.di.unimi.it/ | Nov 04-05 | 20th ACM Conference on Computer and Communications Security | Berlin, Germany | http://www.sigsac.org/ccs/CCS2013/ This issue of Tor Weekly News has been assembled by Lunar, Matt Pagan, dope457, George Kadianakis, Philipp Winter and velope. 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 [24], write down your name and subscribe to the team mailing list [25] if you want to get involved! [24] https://trac.torproject.org/projects/tor/wiki/TorWeeklyNews [25] https://lists.torproject.org/cgi-bin/mailman/listinfo/news-team -- tor-talk mailing list - tor-talk(a)lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

1 0

Re: [Cryptography] programable computers inside our computers (was: Hasty PRISM proofing considered harmful)
by Jerry Leichter 23 Oct '13

23 Oct '13

On Oct 22, 2013, at 9:50 PM, John Ioannidis wrote: > And to add another, there was a presentation on ARM TrustZone, the OS > inside your CPU, that's seems so designed for backdoors that ARM > actually gives tips for running TrustZone invisible to the normal OS. > https://www.hackinparis.com/sites/hackinparis.com/files/Slidesthomasroth.pdf > > > TrustZone sounds like Palladium from 15 or so ago. Have we learned *nothing*? Actually, there is a difference: Palladium had remote attestation built in - it was a selling point. People concentrated on that as the "bad" part, thought the rest could actually be useful. The reference designs let you do whatever you wanted with your own device - you have full access to the trusted elements, could sign your own boot loader if you wanted. Of course, someone providing DRM'ed material could refuse to talk to your system if it didn't attest to running "acceptable" code. The new technologies don't build remote attestation in, so avoid the whole debate. And the base technologies are neutral on the issue of whether you can write your own trusted code. It's the specific implementations that block you from changing the keys, the bootloader, any of the code running in the secure element, etc. The net effect is similar. Nothing keeps a system builder from including remote attestation, but because of the nature of the devices, who is doing the controlling (the cell service providers), and the much higher level of integration of the components (making it harder to pull pieces out of the controlled environment) it really doesn't much matter: If you're successfully talking to the cell network at all, they assume you have "approved" hardware. (Should people start building their own cell hardware from the ground up - certainly possible if you don't care about how practical the device is as a *cell phone*, but extremely difficult if you want something practical - they could always add remote attestation, or some simplified variant that's good enough for the cell provider's purposes, later.) Palladium was subject to political attack because it was open about what it could do for DRM suppliers. The new technologies are harder to attack this way because the responsibility is diffused, and the good and the bad are very thoroughly mixed together. The availability of secure modes in the hardware can be explained as necessary to allow for safe operation in an unsafe world, and in and of themselves harmless - just a safer extension of user space/kernel space isolation. The system builders build things to keep the systems safe from malware, a known and growing problem. The network providers want to protect their networks. Everyone sees the need for heavy protection - including from the device owner - of internal "wallets". -- Jerry _______________________________________________ The cryptography mailing list cryptography(a)metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography

1 0

Re: [Cryptography] programable computers inside our computers (was: Hasty PRISM proofing considered harmful)
by Sebastian Krahmer 23 Oct '13

23 Oct '13

On Tue, Oct 22, 2013 at 12:29:33PM -0400, Tom Ritter wrote: [...] > On 22 October 2013 05:24, Ruben Pollan <meskio(a)sindominio.net> wrote: > > And to add another, there was a presentation on ARM TrustZone, the OS > inside your CPU, that's seems so designed for backdoors that ARM > actually gives tips for running TrustZone invisible to the normal OS. > https://www.hackinparis.com/sites/hackinparis.com/files/Slidesthomasroth.pdf > > These are increasingly worrying me as well. The Secure Element on > Android can at least (if you root and edit the .xml file) be queried > to learn identifiers of what is installed there, if not directly > interact with them. If you are really worrying about that, you are decades too late. :) ARM-TZ-alike features are already there in other CPU's called SMM, VT-x or SVM, or in your board called IPMI or AMT - or more generic OOB-Management. Or if you worry about phones its called SIM and SIM-toolkit (and this list is far from complete). Yes, if you want a real trustbase and crypto that stands, you have to open-source all of it. Do you know what your keyboard controller is doing? :) http://www.youtube.com/watch?v=tmZ4yXuDSNc Sebastian -- ~ perl self.pl ~ $_='print"\$_=\47$_\47;eval"';eval ~ krahmer(a)suse.de - SuSE Security Team _______________________________________________ The cryptography mailing list cryptography(a)metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography

1 0

[drone-list] Arizona military drone operators defraud USG for $1.4M
by Gregory Foster 23 Oct '13

23 Oct '13

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Stars and Stripes (Oct 21) - "21 members of Tucson Air Guard unit indicted on fraud charges": http://www.stripes.com/news/us/21-members-of-tucson-air-guard-unit-indicted… > Many allegedly received more than $100,000 by claiming they lived > in homes outside the Tucson area while on federal active duty > status at various times between November 2007 and September 2010, > officials said. > > “Some of these men and women received benefits in excess of four > and five-times their salaries in temporary duty entitlements,” > Horne said in a news release. "Conversely, our brave men and women > overseas were making pennies on the dollar compared to what this > group was receiving while still going home to their families each > night.” HT @Drone_Wars_UK: https://twitter.com/Drone_Wars_UK/status/392387301965185024 gf - -- Gregory Foster || gfoster(a)entersection.org @gregoryfoster <> http://entersection.com/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org iQIcBAEBCgAGBQJSZ0VhAAoJEMaAACmjGtgj4hUQAJYWels3/jBHneS+e5vI5pa7 ltInMxRaQMp+pFevaMSGp6VMq3jNYQF+OaQG9Gw00m6SaQNKEy7I+mo2PpJXaQP2 MLmmniYWak3tzo6C+p5VVhpa3Z4UAkKrhMIUZFxxA0AjhjkSPOlh/jvfeVCTkgZZ 5QCXvY7PLqbqN6w29Il3rmlH3y7wVuUjM5dXl52VsT2Z2LVD2jB7a27xhQlXrXyQ jNS6IKtwoyE2UgTRQR4m9TFU2wWggmo0yoy4LeEeNyYEksxw2NTJA8JNKyzpkXbA l81XmDdOQXLlpJGoHer66AAgfW6aOqYfGtzm/fHlf/1CJ2n1kdgOhVJmpOb1pfk+ ui3q1BWbUjtI76v1OvBC5epUZKVqeAtLfWvjlU+1ptJWUNTlvtdbeCZo6xLXDHF5 7nAejLPpy3BdmwddD2hhmGsT6ILPQ/DfTSbeTKnktHTWZtpBlpocIn1+mN8Dil3A 2mOJIdGxg/o3GuGw/GFDRqKKhazeytymaQFI4uS6tU45p9DhSwbSwfl+YWGPI+uG qg85wa7H0qybfpBpxJByU4NpDzTMYgqv2A5OEnLjyjX0uqzJx/h46/NMuXWL1I3x VvubfqCBnAYAhymOvuH4kcm7/PWb0d8RqCLBgB7rsaOXqU98m7cH2awjnBbyjc/j R/ExiaAaEBuL6L48Aunu =vNqv -----END PGP SIGNATURE----- -- Want to unsubscribe? Want to receive a weekly digest instead of daily emails? Change your preferences: https://mailman.stanford.edu/mailman/listinfo/drone-list or email companys(a)stanford.edu

1 0

Re: [tor-talk] VOIP and tor
by Matt 23 Oct '13

23 Oct '13

On Tue, 22 Oct 2013 20:18:56 -0600 Mirimir <mirimir(a)riseup.net> wrote: > On 10/22/2013 06:52 PM, Andrew F wrote: > > > Is it the best to use for Voip call on tor? > > I think so. Because it can use UDP through the VPN tunnel, there's > virtually no break-up. Latency is high (1-2 seconds) but that's just a > fact of using Tor. You can set Mumble to TCP mode only and data and voice transmissions will both be sent using TCP. Running my own Mumble server as a hidden service, I got latency that was less than a second on fast circuits. -- tor-talk mailing list - tor-talk(a)lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

1 0

Re: [tor-talk] TBB and tor-relays as a bitcoin wallets
by grarpamp 23 Oct '13

23 Oct '13

On Oct 22, 2013 Joshua Datko <jbdatko(a)gmail.com> TOP POSTED!!! > Also, and I think this was discussed on this list before, offering payment > may actually decrease the number of volunteers [2]. > > I was initially interested in researching a technical way to offer payments > to relays by the clients joining a mining pool and somehow paying the relay > from the pool (something like ring signatures). But there is a lot of While waiting on a capitalist version of Tor, operators can publish their cryptocurrency address in the consensus. Users who wish to donate can write a controller script to match up relays they used with those accepting donations and send off some funds. There are already some addresses present. -- tor-talk mailing list - tor-talk(a)lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

1 0

Re: [tor-talk] VOIP and tor
by Mirimir 23 Oct '13

23 Oct '13

On 10/22/2013 06:52 PM, Andrew F wrote: > Is mumble secure over tor? I've used Mumble, with data transmission in UDP mode, on OpenVPN (in TCP mode) through Tor. Given that you, or someone whom you trust, are running the Mumble server, and that traffic is routed by VPN through Tor, I believe that it's secure. > Is it the best to use for Voip call on tor? I think so. Because it can use UDP through the VPN tunnel, there's virtually no break-up. Latency is high (1-2 seconds) but that's just a fact of using Tor. Voice quality is better than typical cellphone. Mumble was expressly designed for high-latency connections, so it has good interactive tools for optimizing voice quality. > What are the other options? I've heard good things about Jabber. However, all SIP apps depend on third party servers. And SIP servers are much harder to set up than Mumble servers. -- tor-talk mailing list - tor-talk(a)lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

1 0

Re: [Cryptography] programable computers inside our computers
by John Gilmore 23 Oct '13

23 Oct '13

> >> We thought embedded devices were for physical infrastructure > >> engineers to worry about, but now they are proliferating inside > >> our general purpose computers. The next Stuxnet will run on one > >> of the invisible computers inside your computer. It is probably ALREADY running there. With regard to the invisible single-chip computer that sits on every server's motherboard (thanks, you idiots at Intel), I can't say it any better than Dan Farmer: IPMI: Express Train to Hell, v2.0 dan farmer/zen(a)trouble.org http://fish2.com/ipmi/itrain-gz.pdf John _______________________________________________ The cryptography mailing list cryptography(a)metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography

1 0

Re: [zfs] [Review] 4185 New hash algorithm support
by Zooko Wilcox-OHearn 22 Oct '13

22 Oct '13

On Tue, Oct 22, 2013 at 6:05 AM, Schlacta, Christ <aarcane(a)aarcane.org> wrote: > > If any weakened algorithm is to be implemented, how can we know how weak is too weak, and how strong is sufficient? Each professional Cryptographer has given different opinions and all those at our immediate disposal have now been biased. A good way to do that is use an algorithm that has attracted interest from a large number of independent cryptographers. If many cryptographers have invested extensive effort trying to find weaknesses in a algorithm, and haven't reported any, then we can feel more confident that it is less likely to harbor undiscovered weaknesses. Among the algorithms we've been talking about in this thread, SHA-256, HMAC-MD5, Skein, Keccak, and BLAKE are all in this category of being well-studied. Cryptographers publish it if they find a weakness in a reduced-round variant of an important algorithm. You can see a summary of the best results against weakened variants of BLAKE in ¹ (Table 1). ¹ http://eprint.iacr.org/2013/467 The rows labeled "perm." and "cf." are attacks on just one component of the hash, not the whole algorithm. The "# Rounds" column shows how many rounds of a reduced-round variant would be vulnerable to that attack. Don't forget to look at the "Complexity" column, too! That shows (roughly) how many calculations would be necessary to implement the attack. Yes, almost all of them are computations that are completely impossible for anyone to actually execute in the forseeable future. But still, they are the best attack that anyone has (publicly) come up with against those weakened variants of BLAKE so they serve as a heuristic indicator of how strong it is. Among the well-studied algorithms listed above, BLAKE is one of the best-studied. It was one of the five finalists in the SHA-3 contest, and in the final report of the contest ², NIST wrote “The cryptanalysis performed on BLAKE […] appears to have a great deal of depth”. Here is a list of research reports that analyzed BLAKE: ³. ² http://dx.doi.org/10.6028/NIST.IR.7896 ³ https://131002.net/blake/#cr Now, BLAKE2 is not necessarily as secure as BLAKE. We could have accidentally introduced weaknesses into BLAKE2 when making tweaks to optimize it. The paper ¹ looked for such weaknesses and reported that they found nothing to make them distrust BLAKE2. We use a stream cipher named ChaCha ⁴,⁵ as the core of BLAKE and BLAKE2, and nobody has found any weakness in ChaCha. Again, that doesn't mean we didn't manage to screw it up somehow, but I think it helps! If anyone found a weakness in ChaCha, it would *probably* also show them a weakness in BLAKE2, and vice versa. ⁴ https://en.wikipedia.org/wiki/ChaCha_%28cipher%29#ChaCha_variant ⁵ https://tools.ietf.org/html/draft-agl-tls-chacha20poly1305-02 In sum, there has been a lot of independent analysis of BLAKE2, BLAKE, and ChaCha, and I hope there will be more in the future. If you use a reduced-round version of BLAKE2, you can look at these results to see whether anyone has published an attack that would break that reduced-round version. Of course, more rounds is safer against future breakthroughs. It was in that context that I recommended that ZFS use the most rounds of BLAKE2 that it can while still being faster than Edon-R. ☺ That will probably be around 5 rounds. Regards, Zooko Wilcox-O'Hearn Founder, CEO, and Customer Support Rep https://LeastAuthority.com Freedom matters. ------------------------------------------- illumos-zfs Archives: https://www.listbox.com/member/archive/182191/=now RSS Feed: https://www.listbox.com/member/archive/rss/182191/22842876-6fe17e6f Modify Your Subscription: https://www.listbox.com/member/?member_id=22842876&id_secret=22842876-a25d3… Powered by Listbox: http://www.listbox.com

1 0

TBB and tor-relays as a bitcoin wallets
by Trigger Happy 22 Oct '13

22 Oct '13

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi all, Just an idea. In theory : is it possible to implement bitcoin wallet into tor-relay and TBB 1) ? TBB users could tip tor-relays (f.e. 1 satoshi for guard and middle relay, 3 satoshi for exit-node per circuit). Running tor-relays could be profitable or at least cheaper. 1).I think Cody Wilson is working on a bitcoin wallet in a browser. - -- Trigger Happy jabber: triggerhappy(a)jabber.ccc.de torchat: xruq34bnhbqlkjtn -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJSZo5zAAoJEEtm9wC9fGLFvF0P/3HYQSCcZea4iFeTygEkk1Fi s4Us35LVEMHeUx4fODEEXa4PlHMpHtitpBTa6yHRf+XsQLsvca4Xxvo5n1HMq09N FMK9JFFrItCdQO/T/lYNu9Tj3qLU34gpMlzsiN7u3fE8oALAyvHzyAmX0uaJM4Hk p5UsCU9REs5QBIjd8ZLqVodBPj5JHxRnyfxRhcHLZPb5WrrAluIwSOWeQW7GxhpL 3Hed2lZbcdaGyYGqTTBT6/C2KsMsvG097xTZXJKl+x7yL3521ceE9FW1zL7oTE3L i5PJpopbxjhqA3xH68RrSdw7L0Bbp79p3lRUzi4EC1DamHHhFal/tuRfJldhj3m1 4330nXP5pthqufJBql/lklkd7yG0exijq72I2nb9sb/SQLJG7LvF1ga0TKgoMAXC pKRy5NoMW6+UAHtSlFBmeOMKlxsFEbVRAGRhCBlQrbWOIuK+47VfGm7cDaQMID3T AAusJA5z6h+aZlncwyWiJohk753mnrON6lPBD0y9luHFusZ4eUL2Zzy+cqL27xBp mULJR9ABGKW4vndKBBLoH9/wDQmEm1ejL1+74BYRDZrO9mgBADjD50yc4RZ/sK6s JsX/KB/WOLSmYXdk28eS2k+YK+8ke8Y6kuZSAWqEuePqcHiM2+wyHLEhyE8Y7Shv 0JX2WiE0goClZOQfNRH7 =y5Ga -----END PGP SIGNATURE-----

1 0