August 2013 - cypherpunks - lists.cpunks.org

Re: [liberationtech] Google confirms critical Android crypto flaw
by Eugen Leitl 15 Aug '13

15 Aug '13

----- Forwarded message from Maxim Kammerer <mk(a)dee.su> ----- Date: Thu, 15 Aug 2013 15:38:56 +0300 From: Maxim Kammerer <mk(a)dee.su> To: liberationtech <liberationtech(a)lists.stanford.edu> Subject: Re: [liberationtech] Google confirms critical Android crypto flaw Reply-To: liberationtech <liberationtech(a)lists.stanford.edu> On Thu, Aug 15, 2013 at 2:34 PM, Nathan of Guardian <nathan(a)guardianproject.info> wrote: > The best description is here: > http://armoredbarista.blogspot.ch/2013/03/randomly-failed-weaknesses-in-jav… Unbelievable… It seems that PRNG implementers suffer from NIH syndrome. If you are going to use /dev/urandom, then use it all the time, and rely on code that's reviewed and maintained by thousands of kernel people, not just your favorite buggy seeded PRNG du-jour. And even sans the bugs, consider something like the following in Apache Harmony (precursor of Dalvik's class library) [1, p. 131]: iv = sha1(iv,concat(state, cnt)); cnt = cnt + 1; return iv; So they're essentially constructing a state-based bit stream that varies in each block, and hash it with SHA-1 — exposing each intermediate hash value in the middle. Who the hell told them it's safe from cryptanalysis POV? E.g., SP800-90A's Hash_DRBG [2, p. 40] resembles nothing of the sort. [1] http://dx.doi.org/10.1007/978-3-642-36095-4_9 [2] http://csrc.nist.gov/publications/nistpubs/800-90A/SP800-90A.pdf -- 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

2 1

[tor-talk] Flattor: A practical crowdfunded Flattr-like incentive scheme for Tor relays
by Eugen Leitl 15 Aug '13

15 Aug '13

----- Forwarded message from George Kadianakis <desnacked(a)riseup.net> ----- Date: Thu, 15 Aug 2013 15:25:41 +0300 From: George Kadianakis <desnacked(a)riseup.net> To: tor-talk(a)lists.torproject.org Subject: [tor-talk] Flattor: A practical crowdfunded Flattr-like incentive scheme for Tor relays User-Agent: Microsoft Outlook Express 6.00.2900.5843 Reply-To: tor-talk(a)lists.torproject.org ==tldr (Too Long, Didn't Read) Where will Tor's bandwidth come from in 20 years? Will solo volunteers still exist, or will all the bandwidth come from Tor-friendly organizations? Tor incentive schemes are interesting. There are many proposed schemes but their crypto needs to be reviewed and lots of code/spec needs to be written before they can be deployed. This document describes the idea of a Flattr-like crowdfunding model for tor relays. ==Intro (skip if you know why Tor incentive schemes might be useful) One of the goals of Tor is to increase its reach and get tens of millions of Tor users. This makes sense from an anonymity point of view, since an increase on the number of users is also an increase on Tor's anonymity set. One of the problems of scaling Tor to tens of millions of users is that Tor's bandwidth capacity is finite. The current total relay bandwidth is about 4GB/s [0], and it's donated by kind volunteers and various organizations [1]. As the number of users increases, Tor's bandwidth must also increase. Lately the bandwidth coming out of Tor-friendly organizations (like torservers.net, universities, etc.) seems to increase. Currently, there is 50% chance of exiting from an org-controlled exit node, as can be seen in slide 30 of http://freehaven.net/~arma/slides-dimacs13.pdf If this trend continues, Tor might end up looking like the Bitcoin network -- where a number of organizations (mining pools) drive the network. Unfortunately, in contrast with the coin minting of Bitcoin, there is no incentives for organizations to contribute to the Tor network. At the moment, organizations and solo volunteers pay out of their own pocket (or accept donations) to maintain their Tor relays. There must be ways to help reimburse their costs. ==Incentive schemes (feel free to skip if you know this stuff) Incentive schemes for anonymous networks have been extensively researched and there are multiple papers for systems that apply specifically to Tor [2]. Most of those systems require to modify the code of the Tor network, to be able to give "contribution tokens" to relay operators. Then those tokens can be exchanged to get "premium Tor service" or other goods. These systems have a few issues that make them hard to implement and deploy: a) Baking anything inside Tor is a lengthy procedure. Secure designs and code must be written, time must pass for the new code to be deployed and used by the majority of the network, etc. b) These schemes might cause anonymity issues, since the set of people who have "contribution tokens" is smaller than the set of Tor users. The proposed incentive schemes try to fix these issues; for example, LIRA solves it by creating a lottery system (yes, on top of Tor) that rewards "contribution tokens" to random relays. c) Alternative currencies, like "contribution tokens", are not easy to get right. Baking them inside the Tor network is not a trivial task While these proposed "complex" schemes might be The Right Thing for the long-term, we might be able to create an incentive scheme based on already existing technologies; like the bandwidth authorities and Bitcoin. ==Flattor: A simple incentive scheme Flattor is (fictional) software (or a website) that given a Bitcoin wallet and a number of Bitcoins that the user is willing to spend, splits those Bitcoins in chunks and sends them to contributing relay operators. The idea assumes that there is some way to find the Bitcoin address of relay operators. There is no standard way to do so, but operators who are interested in getting reimbursed can put their address in the Contact field of their relay. Flattor uses the bandwidth estimations of Tor to find the contribution factor of each relay. We will assume that these estimates are accurate, since the security of Tor depends on them anyway. As a simplified example, if the Tor network has 4 relays with bandwidth contribution 0.05, 0.05, 0.3 and 0.6 respectively, and the user is willing to spend 1 bitcoin, Flattor will send 0.05, 0.05, 0.3 and 0.6 bitcoins to each relay operator respectively. Of course, this gets more complicated as the number of relays increases, or when only a subset of the relays have a registered bitcoin address, etc. ==Why this might be a good idea It's simple to implement and easy to understand, it doesn't require any Tor code to be written and it can even be started as an unofficial project. Furthermore, it doesn't cause anonymity issues, there are no middlemen, and it doesn't centralize bandwidth to a single relay operator. ==Why this might be a bad idea (This concern is based on a discussion with gmaxwell.) Incentivising Tor relay operators with money is not a good way to run an anonymity network Currently, (we want to believe that) the Tor network is run by a bunch of cypherpunks that are contributing bandwidth because they believe in the Cause. If relay operators start getting money for their bandwidth, we might end up with relay operators that are just in for the money. It might then be easier for a three-letter org to persuade those relay operators to snoop on their users (by giving them double the money they are currently getting). While I agree that this concern is legitimate, I would say that it's pretty far off at the moment: I doubt that anything like Flattor will ever generate a considerable income for anyone. Still, it's something that we should have in mind. (Furthermore, since the Bitcoin blockchain is public you can see how much money each relay operator has gotten so far. Maybe there should be some kind of limit on the number of money each operator should get per time period.) ==Final thoughts There are many details that must be sorted out before Flattr can be implemented. There are also multiple improvements that can be applied on top of the simple model described above. Also, there are ethical issues that spawn up when real money is given to relay operators. My plan was to expand on all these issues in this paragraph, but it seems like I've already spent too many hours writing this document. I'm not planning to implement this system before I hear some opinions from other people. To be honest, I'm not even sure if such an incentive scheme is a good idea, but posting bad ideas to mailing lists is what the Internet is for, right? Thoughts? [0]: https://metrics.torproject.org/network.html#bandwidth [1]: https://metrics.torproject.org/bubbles.html#contact [2]: https://blog.torproject.org/blog/two-incentive-designs-tor http://www-users.cs.umn.edu/~jansen/papers/lira-ndss2013.pdf (see section 'VI. RELATED WORK' of the LIRA paper) -- 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

[guardian-dev] ChatSecure "Burner" accounts
by Eugen Leitl 15 Aug '13

15 Aug '13

----- Forwarded message from Nathan of Guardian <nathan(a)guardianproject.info> ----- Date: Wed, 14 Aug 2013 08:38:09 -0400 From: Nathan of Guardian <nathan(a)guardianproject.info> To: Guardian Dev <guardian-dev(a)lists.mayfirst.org> Subject: [guardian-dev] ChatSecure "Burner" accounts User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130804 Thunderbird/17.0.8 One of the new features, I am finishing implementation on is the ability to quickly create "burner" accounts within ChatSecure v12. As of last nights alpha, you can now create new accounts directly from the app, on supported services such as Jabber.ccc.de and Dukgo.com. In the default mode, you choose a username, password, etc, yourself. The concept of a burner account is that you can quickly create a new clean account with no identifying or memorable details, and have that account only exist on your device, within the encrypted ChatSecure SQLCipher data store. In the burner mode, a random username and password will be generated, all registration and communication will be required to be done over Orbot/Tor, and possibly, we will only support using an XMPP service that has a Tor hidden service. One you are logged in, you can then use the typical invite/add contact feature to start a chat with someone, either on the same box, or any other federated XMPP service. Ideally, the other person is also using a burner account. Any other thoughts on this feature? Other similar implementations or concepts to consider? Perhaps this should be a Force OTR-only as well, and maybe the account auto-deletes after a time period or when you exit the app? Thanks for your feedback, and please, try the latest alpha if you have not yet moved onto v12. It is getting very close to stable, and we are very nearly done with all the new features. +n _______________________________________________ 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

1 0

[liberationtech] We'll make ourselves a GNU Internet.. GADS, PSYC, distributed search
by Eugen Leitl 15 Aug '13

15 Aug '13

----- Forwarded message from carlo von lynX <lynX(a)time.to.get.psyced.org> ----- Date: Thu, 15 Aug 2013 09:38:36 +0200 From: carlo von lynX <lynX(a)time.to.get.psyced.org> To: liberationtech(a)mailman.stanford.edu Subject: [liberationtech] We'll make ourselves a GNU Internet.. GADS, PSYC, distributed search User-Agent: Mutt/1.5.20 (2009-06-14) Reply-To: liberationtech <liberationtech(a)lists.stanford.edu> You broke the Internet. We'll make ourselves a GNU one. https://gnunet.org/internetistschuld http://internetistschuld.de http://www.reddit.com/search?q=gnu+internet This is the video from the talks given by Christian Grothoff, Carlo von lynX, Jacob Appelbaum and Richard Stallman in Berlin on August 1st. The talks are in English, even though the welcoming words are in German. Christian Grothoff's talk summarized the recent revelations about PRISM and their implications for non-American citizens, industries and governments. It then presented technical solutions towards a secure and fully decentralized future Internet, which would address key challenges for self-determined life created by the world-wide police state. Interesting details on this: - A new cryptographic method for a privacy-capable DNS/DNSSEC replacement, called GADS. - A faster and smarter extensible messaging syntax than XML and JSON, called PSYC. - A strategy for distributed and liberated Internet search, called RegEx. Carlo von lynX gave a presentation on how secushare intends to provide messaging and Facebook-like functionality on top of GNUnet. Keywords: Scalability by multicast; Social graph vs. Onion routing; Unsafety of your own server. Richard Stallman and Jacob Appelbaum added closing notes of free software and free hardware and responded to questions. It's not about how much you want to make believe you got nothing to hide. It's about your civic duty to not be a predictable populace. Big thanks to the Pirate Party for providing the venue and the recording technology. -- 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

[Bitcoin-development] bitcoinj 0.10
by Eugen Leitl 15 Aug '13

15 Aug '13

----- Forwarded message from Mike Hearn <mike(a)plan99.net> ----- Date: Wed, 14 Aug 2013 14:26:27 +0200 From: Mike Hearn <mike(a)plan99.net> To: Bitcoin Dev <bitcoin-development(a)lists.sourceforge.net> Subject: [Bitcoin-development] bitcoinj 0.10 Hello, I'm pleased to announce version 0.10 of bitcoinj, a Java library for writing Bitcoin applications. BitcoinJ has been used to create everything from end-user wallet apps to network crawlers to SatoshiDice. To learn how to obtain bitcoinj 0.10, please see the following page: https://code.google.com/p/bitcoinj/wiki/UsingMaven The v0.10 release is signed by Andreas Schildbach's GPG key. The git hash of the release is 777e6781d789. This paragraph is signed by the same Bitcoin key as with previous releases (check their release announcements to establish continuity). Signature: H9Nl7FPnmrUOmjhUZ0+xB4YW3q5F5gIkGdvllsDWmWYvOkNQHAE9jZE0I/qE1VfLPeMV+Rzo7geTB43uDSFSMek= *New in this release* - An implementation of *micropayment channels* was added. There have been many bugfixes and improvements since the first announcement. This feature allows you to set up a 1:1 payment relationship with a remote server and after a short setup process send very tiny payments, very rapidly. It's suitable for metered billing applications. An article, "Working with micropayments" explains how to use it. This work was a joint effort between Matt and myself. - A simple sublibrary has been added that provides async IO based client/server classes that transmit length prefixed protocol buffers. - Thanks to Matija Mazi, some classes have been added that implement *the BIP 32 deterministic wallet algorithm*. Note that these classes are not yet used elsewhere in the system and full deterministic wallet support is therefore not available, however, a low level API is available for experimentation. That API is very likely to change in future releases so don't get too attached to it. - Thanks to Gary Rowe, we have integrated *a new Maven plugin* that checks the SHA1 hashes of downloaded dependencies against a hard-coded list. This means that even if an upstream Maven repository or developer were to be compromised, library dependencies could not be switched out for corrupted versions without someone noticing. For 0.10 the dependency hashes were just initialised based on what was already downloaded. In future, reproducible builds of upstream dependencies and auditing of changes would provide better security. You can and should use Gary's plugin<https://github.com/gary-rowe/BitcoinjEnforcerRules> in your own projects to defend against a possible compromise of the bitcoinj repository. - *Callback handling* has been much improved. Each event listener can have an Executor specified which takes responsibility for running the callback. If you don't specify one they run by default on a single background thread, the "user thread", instead of the origin framework threads. This means your callbacks no longer need to be thread safe as they're always run serially. You can also change the default executor if you would like to control the thread on which callbacks run, for example to marshal them into your GUI toolkit thread automatically. This fixes some of the most painful parts of the pre-0.10 API, for instance that transaction confidence listeners were not allowed to re-enter the library. - *Exception handling* has also improved. You can assign a global Thread.UncaughtExceptionHandler which receives any exceptions thrown on the user thread (i.e. by your own event listeners), as well as any internal exceptions thrown by network threads (like inability to parse a message sent by a remote peer). Because your listeners now run on a separate thread by default, you can no longer accidentally cause internal data corruption or prevent other callbacks from running by leaking exceptions out of your callbacks; a subtle knife-edge in the previous API. - Support for *automatic wallet key rotation* has been added. - We now require Bloom-capable (0.8+) peers by default and will disconnect from older nodes. This avoids accidental bandwidth saturation on mobile devices. - The wallet now accepts timelocked transactions if it created them itself. - The wallet can be told to empty itself out, in which case the fee will be subtracted from the total amount instead of added. This simplifies the common case of wanting to send your entire balance whilst still including a fee. - Some JNI peers for event listeners were added. Auto-generated JNI bindings are experimental and not yet merged in to the mainline codebase: for now they are available as part of a separate project on github. This work allows you to access the bitcoinj API using relatively natural looking C++ code and an embedded JVM. - You can now register custom PeerFilterProvider implementors to add things to Bloom filters that aren't necessarily in wallets. - We have begun adding nullity annotations to the API. Combined with a strong static analysis engine like FindBugs or the IntelliJ Inspector, you can find cases where you aren't handling possible null pointers. Note that you should configure your static analysis system to understand the Guava Preconditions assertions, as otherwise you will get false positives. - You can now control how much information Wallet toString() dumps contain more precisely. Extensions can contribute to a wallets debug dump as well, and transaction data is now optional. - Documentation: The getting started tutorial and PingService example were rewritten. New articles were added that cover optimising chain sync and using the library from non-Java languages. Existing articles were also extended and refreshed. - Many bug fixes and new methods. You should upgrade as soon as possible to get the bug fixes, in particular, one that could cause transactions inside the same block to be incorrectly re-ordered when using Bloom filtering (which can affect the wallet). The library code now has more internal annotations to help static analysis engines, and several bugs were fixed as a result of that. *API Changes* - The ScriptBuilder class now takes TransactionSignature objects, these wrap a raw ECDSA signature and the SIGHASH flags together, with utility methods to work with them. - The Locks class has been renamed to Threading. The thread on which callbacks run has been changed, see above. - The WalletEventListener.onKeyAdded method became onKeysAdded and now takes a list, to make processing of bulk adds more efficient. - BitcoinURIParseException is now checked so you can't forget to handle bogus URIs. - The Wallet.toString(..) method has additional parameters now so you can control what is included in the dump. *Known issues* * * Please see the limitations and missing features<https://code.google.com/p/bitcoinj/wiki/Limitations> page. This page has been fleshed out since the last release with common issues and missing features. A few issues were also fixed and removed. ------------------------------------------------------------------------------ Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk _______________________________________________ Bitcoin-development mailing list Bitcoin-development(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development ----- 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

Switching power supplies
by Chris Olesch 15 Aug '13

15 Aug '13

I'm in the process of researching current power supply technologies to create a robust bench supply for my father. My dad is an rc quad copter enthusiast and enlisted me to create him a supply. His requirements are 13-48v with a max wattage of 1200w. Can anyone recommend any good reading materials on switching designs? I'm also reading thru rsw's thesis as well. In an ideal world I'd like to make the supply modular and also have built in freq width/delay speed control. I'm also looking to build a 6 amp dc supply for my solid state peltier experiment (currently using an old dell ps, but this isn't very portable...lol) -Chris. -- -- -- -Christopher Olesch *"Affordable IT Services for Non-Profit & Small Business"* || http://www.ngotechnology.org/ || http://www.linkedin.com/in/chrisoleschjr *Masonic Affiliations:* || http://www.scottishritechicago.org || http://www.supremecouncil.org/ || http://www.ilmason.org/ *Online Artistic Portfolio* || http://cjolesch.deviantart.com/

4 5

changing computers
by Riad S. Wahby 14 Aug '13

14 Aug '13

All, I'll be moving the list from one machine to another in the next day or so. There may be some brief outages. Thanks for understanding. -=rsw

2 2

[tor-talk] Tor Weekly News — August, 14th 2013
by Eugen Leitl 14 Aug '13

14 Aug '13

----- Forwarded message from Lunar <lunar(a)torproject.org> ----- Date: Wed, 14 Aug 2013 08:46:07 +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 — August, 14th 2013 User-Agent: Mutt/1.5.21 (2010-09-15) Reply-To: tor-talk(a)lists.torproject.org ======================================================================== Tor Weekly News August 14th, 2013 ======================================================================== Welcome to the seventh issue of Tor Weekly News, the weekly newsletter that covers what is happening in the fast-paced Tor community. New Tor Browser Bundle releases ------------------------------- Mozilla released Firefox version 17.0.8esr [1] on August 6th, fixing several release critical bugs. Three days later, the stable, beta and alpha versions of the Tor Browser Bundle were updated, along with Tails (see below). The stable 2.3.25-11 and 2.4.15-beta-2 also updates HTTPS Everywhere, PDF.js, NoScript and libpng to their latest version. Both bundles had a localization issue which was fixed in the subsequently released 2.3.25-12 and 2.4.16-beta-1 [2]. Before updating your browser to the latest version, please pause and admire the enhanced download page [3]. Kudos to J.M. Todaro for the design and patches [4] and Andrew for the final integration. The pluggable transports bundles have also been updated to 2.4.15-beta-2-pt1 [5]. Like previously, they contains flash proxy and obfsproxy configured to run by default. Using flash proxy requires a few extra steps [6], as before. For more experimental matters, the new 3.0 series has seen the release of alpha3 [7]. On top of the previous updates, several other small improvements were made: in the new launcher and build system, in fingerprinting fixes and in a possible anonymity threat for Windows users coming from cloud anti-virus solutions [8]. This is another opportunity to play with the new build system that should produce byte-to-byte identical results. Please have a try [9] and report any discrepancies with Mike Perry’s builds. [1] https://www.mozilla.org/en-US/firefox/17.0.8/releasenotes/ [2] https://blog.torproject.org/blog/new-tor-02416-rc-packages-and-updated-stab… [3] https://www.torproject.org/projects/torbrowser.html.en#downloads [4] https://blog.torproject.org/blog/pluggable-transports-bundles-2415-beta-2-p… [5] https://trac.torproject.org/projects/tor/wiki/FlashProxyHowto [6] https://trac.torproject.org/projects/tor/ticket/2109#comment:7 [7] https://blog.torproject.org/blog/tor-browser-bundle-30alpha3-released [8] https://bugs.torproject.org/9195 [9] https://gitweb.torproject.org/builders/tor-browser-bundle.git/blob/HEAD:/RE… Tails 0.20 has been released ---------------------------- The 32nd release of Tails is out [10]. It fixes several security issues, and all users are advised to upgrade [11]. Among other small bugfixes, minor improvements and translation updates, this release tightens the security around Pidgin — by removing support for protocols other than IRC and XMPP — and restricting access to the ptrace(2) system call for unprivileged users. Download [12], burn, and upgrade [13]! [10] https://tails.boum.org/news/version_0.20/ [11] https://tails.boum.org/security/Numerous_security_holes_in_0.19/ [12] https://tails.boum.org/download/ [13] https://tails.boum.org/doc/first_steps/usb_upgrade/ New release candidate for the 0.2.4 tor branch ---------------------------------------------- Roger Dingledine announced the release of tor 0.2.4.16-rc [14], the latest incarnation of the 0.2.4 series. This release include several major and minor bugfixes. The most important one is probably a crash that can be triggered remotely via badly formatted INTRODUCE1 cells. Roger advises: “Anybody running a hidden service on the experimental 0.2.4.x branch should upgrade”. Erinn Clark has updated the beta version of the Tor Browser Bundle [2] for a wider audience of testers. [14] https://lists.torproject.org/pipermail/tor-talk/2013-August/029344.html About Tor Browser usability --------------------------- Last week events [15] sparked a good amount of discussions on Tor Browser usability. Several discussions on tor-talk and in other places revolved around the idea that “JavaScript should be disabled by default”. scarp wrote a good summary [16] on why it is not so simple: “I understand that JavaScript was enabled globally in the Tor Browser Bundle for usability reasons as well as to prevent browser fingerprinting. […] If the torproject were to disable it by default, that would not ensure that users are protected in the future by similar methods. Sites can be written in a way that if you do not allow JavaScript they simply won’t work at all. If I was writing an exploit I’d do this to frustrate users so hopefully they enable JavaScript and accept my exploit.“ Roger Dingledine also improved [17] the relevant question in Tor FAQ [18]. One possible solution to satisfy contradicting requirements would be to add a “security slider” [19] that would allow users to easily trade off web compatibility over security. The slider would have three or four different positions that would gradually deactivate more and more features of the browser. One has to understand that the “most secure” should probably disable loading of any pictures. This also impacts the Tor Browser anonymity set but this is probably a trade off that can be afforded given the actual size of the Tor Browser user base. scarp had also pined another big usability problem related to updating: “This exploit wasn’t new. […] Users running the latest Tor Browser Bundle didn’t have any issues as their browsers had been patched. It is inappropriate for a web browser to not be automatically updated.” Nick Mathewson went back [20] on the latest plan that was discussed during the last summer dev. meeting [21] to simply build upon Firefox update mechanism. The next step is to do a proper review. Hopefully, given it is “mature and widespread” and has been “proven to update Firefox”, we will not “run screaming for the hills” when looking at the disadvantages. On a more general level, an unexpected comment came from Brendan Eich (Mozilla’s chief technology officer) on Twitter [22]: “Maybe we should just adopt, support, and bundle Tor in Firefox...” David Dahl subsequently opened a bug report in Mozilla’s tracker to discuss a way forward [23]. Mike Perry commented on a thread [24] on the liberationtech mailing list: “In short, I am excited by this news, and I look forward to improving our communication and cooperation with Mozilla on this front.” [15] https://blog.torproject.org/blog/tor-weekly-news-%E2%80%94-august-7th-2013 [16] https://lists.torproject.org/pipermail/tor-talk/2013-August/029266.html [17] https://lists.torproject.org/pipermail/tor-talk/2013-August/029364.html [18] https://www.torproject.org/docs/faq.html.en#TBBJavaScriptEnabled [19] https://bugs.torproject.org/9387 [20] https://lists.torproject.org/pipermail/tor-dev/2013-August/005228.html [21] https://trac.torproject.org/projects/tor/wiki/org/meetings/2013SummerDevMee… [22] https://twitter.com/BrendanEich/status/364265592112414720 [23] https://bugzilla.mozilla.org/show_bug.cgi?id=901614 [24] https://mailman.stanford.edu/pipermail/liberationtech/2013-August/010650.ht… Tails 2013 summit ----------------- The Tails team has sent a report on their 2013 development summit [25] for which “a bunch of people spend a dozen days together in July”. Read the report in full for all the details. Some highlights: task tracking have been moved to Redmine [26], tasks fit for new contributors has been better identified [27], progress has been made to move Tails to the current Debian stable release [28], the roadmap has been updated [29]. Communication channels are going to change a little bit “to ease involvement of new contributors, to make more workload sharing possible, and to be able to provide better user support”. As a start a new user support mailing list was created [30]. Subscribe if you have questions or want to help fellow Tails users. A lot of discussions revolved around “the growth of the project: given the growing number of users and our super-short release cycle, it is a challenge to keep the project sustainable and maintainable in the mid/long term.” Give the current project exposure, the report rightfully concludes: “Tails is living decisive times, so we expect the next year to be pretty interesting. You can perhaps make the difference, so do not hesitate joining the dance [31]!”. [25] https://tails.boum.org/news/summit_2013/ [26] https://labs.riseup.net/code/projects/tails [27] https://labs.riseup.net/code/projects/tails/issues?query_id=112 [28] https://labs.riseup.net/code/issues/6015 [29] https://labs.riseup.net/code/projects/tails/roadmap [30] https://tails.boum.org/support/tails-support/ [31] https://tails.boum.org/contribute/ Three new proposals ------------------- On Monday, Nick Mathewson robbed everyone of his “I’m a little teapot” performance [32] by releasing the following three new proposals: Proposal 219 [33] has been written a year ago by Ondrej Mikle. It is currently at draft stage. Its goal is to make Tor support any DNS query type and also support full DNSSEC resolution. The latter is important as it provides “protection against DNS cache-poisoning attacks” but is made tricky given a routine hostname resolution with DNSSEC “can require dozens of round trips across a circuit”. In another draft proposal [34], Nick Mathewson describes a plan for a smooth transition from the current 1024-bit RSA keys used for router identity and TLS links to Ed25519-SHA-512 [35] keys. Several small details still have to be ironed out. This proposal does not address hidden service keys. They will have to be addressed in another proposal once an agreement has been reached regarding the best crypto scheme [36]. Now that the ntor onionskin handshake [37] has been implemented in 0.2.4, we could get better forward secrecy by having clients top sending CREATE_FAST cells. Nick Mathewson has issued proposal 221 [38] to detail the reasons and the implications of such change. All these proposals are now up for discussions on the tor-dev mailing list. [32] https://twitter.com/nickm_tor/status/365527533627777025 [33] https://gitweb.torproject.org/torspec.git/blob/HEAD:/proposals/219-expanded… [34] https://gitweb.torproject.org/torspec.git/blob/HEAD:/proposals/220-ecc-id-k… [35] https://bugs.torproject.org/8106 [36] http://ed25519.cr.yp.to/ [37] https://gitweb.torproject.org/torspec.git/blob_plain/HEAD:/proposals/216-nt… [38] https://gitweb.torproject.org/torspec.git/blob/HEAD:/proposals/221-stop-usi… Miscellaneous news ------------------ Jens Kubieziel researched how to get a GnuPG version for Windows in a secure way [39], something needed for users that would like to properly verify the Tor Browser Bundle signatures on Windows systems. [39] https://lists.torproject.org/pipermail/tor-talk/2013-August/029256.html George Kadianakis wrote on “how to deploy your very own pluggable transport” [40] explaining what to do before, while and after coding a new pluggable transport. Given they were designed to be “pluggable”, “it should be easy to write new [ones]”. So be sure to read these advices and start experimenting! [40] https://lists.torproject.org/pipermail/tor-dev/2013-August/005231.html A new round of GSoC reports arrived to the tor-dev mailing list: Johannes Fürmann about EvilGenius [41], Cristian-Matei Toader about Tor capabilities [42], Hareesan about the Steganography Browser Extension [43], and Kostas Jakeliunas about the searchable metrics archive [44]. All of them seems to be making good progress. Let’s wish them success for the last six weeks! [41] https://lists.torproject.org/pipermail/tor-dev/2013-August/005237.html [42] https://lists.torproject.org/pipermail/tor-dev/2013-August/005238.html [43] https://lists.torproject.org/pipermail/tor-dev/2013-August/005243.html [44] https://lists.torproject.org/pipermail/tor-dev/2013-August/005244.html More reports came from the July 2013 wave: the Tor Help Desk by Runa Sandvik [45], and Moritz Bartl [46]. [45] https://lists.torproject.org/pipermail/tor-reports/2013-August/000310.html [46] https://lists.torproject.org/pipermail/tor-reports/2013-August/000311.html Andrew Lewman gave a talk during the US National Network to End Domestic Violence’s (NNEDV) annual technology summit. His presentation [47] covered “a quick overview of Tor, why I’m here talking about domestic violence and intimate partner abuse, and what we’re doing to help.”. Be sure to read his report [48] in full. [47] https://svn.torproject.org/svn/projects/presentations/2013-07-30-NNEDV-Pres… [48] https://blog.torproject.org/blog/nnedv-tech-summit-2013-report Thanks to Paul Templeton from CoffsWiFi [49], and nsane [50] for running new Tor website mirrors. [49] https://lists.torproject.org/pipermail/tor-commits/2013-August/060352.html [50] https://lists.torproject.org/pipermail/tor-commits/2013-August/060583.html Several people are trying to assemble localization teams for Tails: Miriam Matar for Arabic [51], irregulator for Greek [52], hemlockii for Turkish [53]. Tails policy regarding website translations [54] specifies that “a team of translators, not just one person, is necessary”, so please join if you can help! [51] https://mailman.boum.org/pipermail/tails-l10n/2013-August/000637.html [52] https://mailman.boum.org/pipermail/tails-l10n/2013-August/000646.html [53] https://mailman.boum.org/pipermail/tails-l10n/2013-August/000652.html [54] https://tails.boum.org/contribute/how/translate/ Help Desk Roundup ----------------- Below is a summary of some frequent questions received at the Tor help desk this past week: Users are frequently confused by the message they receive from GetTor. Currently the Tor Browser Bundle is too large to send over GetTor, so users instead receive three mirrors with a link to a page with all available translations of the Tor Browser Bundle. Many users email the help desk unsure of what this page means or which package they need. A number of users asked whether or not they needed to disable JavaScript in the Tor Browser Bundle. While the vulnerability in Firefox does not affect the latest Tor Browser Bundle, disabling JavaScript globally will reduce one’s risk of being affected by future JavaScript exploits. Users were asked to choose for themselves between greater protection inside the browser or a browsing experience with more functionality enabled. Upcoming event -------------- Aug 14 | Roger at 22nd USENIX Security Symposium | Washington, DC, USA | https://www.usenix.org/conference/usenixsecurity13 This issue of Tor Weekly News has been assembled by Lunar, malaparte, mttp, Phoul, Tails developers, David Fifield, Nick Mathewson, and Karsten Loesing. 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 [55], write down your name and subscribe to the team mailing list [56] if you want to get involved! [55] https://trac.torproject.org/projects/tor/wiki/TorWeeklyNews [56] 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

Re: [cryptography] LeastAuthority.com announces PRISM-proof storage service
by Eugen Leitl 14 Aug '13

14 Aug '13

----- Forwarded message from Nico Williams <nico(a)cryptonector.com> ----- Date: Tue, 13 Aug 2013 15:10:36 -0500 From: Nico Williams <nico(a)cryptonector.com> To: ianG <iang(a)iang.org> Cc: cryptography(a)randombit.net Subject: Re: [cryptography] LeastAuthority.com announces PRISM-proof storage service On Tue, Aug 13, 2013 at 12:02 PM, ianG <iang(a)iang.org> wrote: > Super! I think a commercial operator is an essential step forward. A few points: - if only you access your own files then there's much less interest for a government in your files: they might contain evidence of crimes and conspiracies, but you can always be compelled to produce those - if you share files then traffic analysis will reveal much about what you're up to, and there may be much interest in getting at your files' contents. - commercial operators who give you software to run can compromise (or allow governments to compromise) you even if they are not technically an end-point[*] for your end-to-end protocols. - it's really not easy to defeat the PRISMs. the problem is *political* more than technological. - i'm not trying to detract from Tahoe-LAFS -- it's a spectacular idea, I wish it well, and I generally endorse filesystems of this sort. [*] In Tahoe-LAFS, ZFS, and any other similar filesystems, there is only one end-point: the client(s); the server, in particular, is NOT an end-point. Nico -- _______________________________________________ cryptography mailing list cryptography(a)randombit.net http://lists.randombit.net/mailman/listinfo/cryptography ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5

1 0

[liberationtech] Zwiebelfreunde take over popular onion.to Tor gateway
by Eugen Leitl 14 Aug '13

14 Aug '13

----- Forwarded message from Moritz Bartl <moritz(a)torservers.net> ----- Date: Tue, 13 Aug 2013 20:59:22 +0200 From: Moritz Bartl <moritz(a)torservers.net> To: liberationtech <liberationtech(a)lists.stanford.edu> Subject: [liberationtech] Zwiebelfreunde take over popular onion.to Tor gateway User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 Reply-To: liberationtech <liberationtech(a)lists.stanford.edu> Hi Libtechies, I hope you don't mind me putting this press release here. Please spread if you like it. ---------------------------------------------------------------------- # Zwiebelfreunde take over popular onion.to Tor gateway (Dresden, 13.8.2013) The non-profit organization Zwiebelfreunde e.V. is known for the “Torservers” project, which over the past years has grown into a global network of organizations that maintain server infrastructure for the open anonymization network Tor. Today, Zwiebelfreunde has taken over a very popular web gateway for Tor hidden services, onion.to. Tor hidden services provide anonymity for website owners, mail providers, chat systems and other Internet services. Hidden services are designed to be accessed using Tor Browser, which additionally provides anonymity for users of the service. Web gateways such as onion.to provide a convenient way to reach hidden services using a regular browser without having to install Tor. A side effect is that the broad world of hidden services are exposed to search engines and can thus be indexed and found. The trade-off is that users lose anonymity: Both the gateway and the hidden service can track users across visits, and determine the user's IP address. That is why Zwiebelfreunde strongly encourages people to download Tor Browser instead. “By exposing hidden services to the public, we hope to attract even more users and widen the spectrum of available services within the Tor network.”, says Zwiebelfreunde founder and president Moritz Bartl. “I can imagine privacy-friendly email services to be based fully on hidden services in the future, for example.” The current gateway server is located in Iceland, and another one will be added in the near future. https://www.onion.to/ An example hidden service can be found at https://duskgytldkxiuqc6.onion.to/ # Zwiebelfreunde e.V. The German non-profit association Zwiebelfreunde e.V. serves as a platform for projects in the area of safe and anonymous communication. The organization facilitates and participates in educational events about technological advances in the area of privacy, and connects professionals to spread knowledge and experience on these fields. “Zwiebelfreunde” is German for “Friends of the Onion”, as a reference to Onion Routing, the name of the concept behind Tor for anonymizing communication: Messages are passed through relays that each removes one layer of encryption, like peeling the skin of an onion. Contact # Contact Moritz Bartl Zwiebelfreunde e.V. c/o DID Dresdner Institut für Datenschutz Palaisplatz 3 D-01097 Dresden Germany press(a)torservers.net Tel.: +49-(0)351 / 212 960 18 Fax.: +49-(0)911 / 308 4466 748 http://www.torservers.net/ http://www.twitter.com/torservers/ -- 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