- tor-dev - lists.torproject.org

[Stegotorus] Fundamental problem with ack/retransmission mechanism
by vmonmoonshine＠gmail.com 24 Jun '13

24 Jun '13

Hello Zack, In testing the retransmission algorithm, I encounter situations that the ack/retransmission algorithm is unable to resolve by design. It happens when the header of a packet gets deliver but the middle part gets dropped. For example in the following scenario Server sends packet 1 len 4k packet 1 gets lost Server sends packet 2 len 64k the last 60kb of packet 2 gets lost client receives packet 2 partially (4k) and waits for the 60k to come. client sends ack to the server saying that packet one is lost server retransmits pack 1 client consider packet 1 as a part of packet 2, and thinks that now it has 8k of packet 2 client again sends ack to the server saying that packet one is lost server retransmits pack 1 client thinks now it has 12K of packet 2 client again sends ack to the server saying that packet one is lost server retransmits pack 1 client thinks now it has 16k of packet 2 etc Soon the transmit queue on the client side will get filled up by the ack packets, cause the client won't realize its mistake before it receives 64k of garbage and be able to compute the mac. Hence the server and the clients will remain in this deadlock for ever. Originally, Stegotorus was dropping any circuit with full transmit queue. But this was causing lots of problem because lots of time the client lags behind the server for a while to process all the packet and sends ack. If ack/retransmit by design wasn't meant to recover from partial packet lost and was only a defense for complete packet lost, then the dropper proxy isn't doing a good job simulating the intended threat model. Otherwise, if the ack/retransmit was meant to withstand partial packet drop, then we need to redesign it so it doesn't get trapped in such a deadlock. Maybe we should have a timer so the circuits with full transmit queue gets a grace period before getting dropped. This is not specific to chop protocol. I'm wondering how TCP is dealing with such a situation. Thanks, Vmon

4 6

Standalone flash proxy
by Arlo Breault 21 Jun '13

21 Jun '13

https://trac.torproject.org/projects/tor/ticket/7944 Hello, I wrote a little wrapper to provide a headless flash proxy. It requires node.js >= v0.8.x To install and run, > npm install -g flashproxy # adds the flashproxy bin to your path > flashproxy Or you can, > git clone -b nodejs https://github.com/arlolra/flashproxy.git > cd flashproxy/proxy > npm install > npm start I'm looking for testers. Most of the time the facilitator won't return any clients. That's expected. Feedback appreciated. Thanks, Arlo

2 1

Discussion on the crypto migration plan of the identity keys of Hidden Services
by George Kadianakis 19 Jun '13

19 Jun '13

Greetings, I'm supposed to write a Tor proposal for the migration of the long-term identity keys of Hidden Services. When I began writing the proposal, I realized that some of my choices might not be appreciated by Hidden Service operators, and that starting a discussion thread might be a good idea before writing the proposal. The problem with the current long-term HS identity keys is that they are RSA-1024 keys which are considered weak, and they need to be upgraded to a cryptosystem with higher security properties. One of the main issues with this operation, is whether Hidden Services will be accessible using their *old* identity keys even after the migration. That is, when we change the identity keys of a Hidden Service, its onion also changes (since the onion is the truncated hash of its public key). This will be quite problematic for Hidden Services that have a well-established onion address. There are basically two ways to do this: a) After the transition, Hidden Services can be visited _only_ on their _new_ onion addresses. This is quite brutal, but it's the most secure and unambiguous option (might also be easier to implement and deploy). This change can be enforced both on the client-side, by rejecting any old RSA-1024 HS keys, and on the server-side, by only publishing the new keys in HS descriptors. To make the transition easier, we could prepare a tool that generates a new identity keypair before the flag day, so that Hidden Service operators can learn their future onion address beforehand and announce it to their users. b) After the transition, Hidden Services can use both old and new onion addresses. This might result in a more harmonious transition, where Hidden Services advertise their new onion address to users that visit them in their old address. .oO(It would also be interesting to do a redirection on the Tor protocol layer ("I got this descriptor by querying for the old onion address, but it also contains a new onion address. I should probably use the new one."), but I don't think it's possible to redirect the user without knowledge of the application-layer protocol (e.g. 302 for HTTP). Still, a Tor log message might be helpful.) The cons of this approach is that supporting both addresses might make the HS protocol more complicated and painful to implement, and it might also result in some Hidden Services never moving to the new onion addresses since clients can still visit them using the old insecure ones. This approach has a stricter variant, where the old addresses can only be used during a transitionary period (a few months?). After that, clients _have_ to use the new addresses. Of course, this means that we will have to do two flag days, coordinate Tor releases, and other no fun stuff. I'm probably moving towards the latter option because the former will make many people unhappy. Thoughts? (This is not a thread to select the cryptosystem we are going to use. It will derail the discussion, and we might also need to select a specific type of cryptosystem in the end (e.g. a discrete-log-based system) so that schemes like https://trac.torproject.org/projects/tor/ticket/8106 can be possible.).

16 29

Running Atlas Application
by abhiram 18 Jun '13

18 Jun '13

Hello, I am trying to get the Atlas application to run. After installing the required python packages, I keep getting this error. Traceback (most recent call last): File "run.py", line 34, in <module> from tornado.util import b, bytes_type, import_object, ObjectDict ImportError: cannot import name b Its seems like a version problem with tornado. If so, what version should I be using. I am running python 2.7.3 and tornado 3.0.3. Thanks -- Abhiram Chintangal Graduate Student Florida State University Computer Science Department (850) 980-4954

2 2

Re: [tor-dev] [liberationtech] Help test the new Tor Browser!
by Bernard Tyers - ei8fdb 17 Jun '13

17 Jun '13

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Congratulations Tor Project. Well done to Mike Perry and all the contributors. I've tested it on Mac OS X 10.6.8 and Debian 6.0 Squeeze and I had no technical issues on either. First launch (using clear Internet connection) took approx 40-50 seconds on each. (Debian was running as a VM on a Macbook Pro) The biggest usability hurdle for Tor (IMO) was having the browser launching separately to the Tor application. I've tested with users and this was a huge confusion for them. It wasn't a browser as *they* understand one. Now it is. First prong of the attack: this is how privacy enhancing software should behave - the exact same as all other software. Now Tor is even better. Second prong of the attack. Run more exit nodes. - From the quick run through I did, here are some(possibly minor) suggestions: 1. The installed application icon is as follows http://diymobileusabilitytesting.net/bernard/skitches/tbb-3.0alpha1-icon1-2… However when the application is opened, the application icon is this http://diymobileusabilitytesting.net/bernard/skitches/tbb-3.0alpha1-icon2-2… It may be confusing for someone who was not familiar with the different icons used by the TP. 2. The copy displayed during the initial install ("Before the Tor Browser Bundle tries to connect to the Tor network, you need to provide information about this computer's Internet connection) could possibly be reworded to give some context as to *why* it is being asked for. (Possibly reposition the copy to above the connection steps) Alternatively, is it possible for the install to run these two tests and determine to correct outcome? Ie. 1. Run some "tests" to determine if the Internet connection is clear of obstacles, then 2. Run some "tests" to check if the Internet connection is censored/filtered. Based on the outcome of these tests, Tor could then configure the connection as necessary. I could see this step being confusing for users not familiar with their Internet connection. 3. It would be interesting to see the numbers of users who actually follow the "Test Tor Network Settings" link. Once the TBB has installed and displays the "Congratulations! This browser is configured to use Tor." page, are users guaranteed to be connected to the Tor network? If so is there any need for the Test Tor Network..." link? Is it possible to display that information on the startpage? It is also very nice that the user preferences have been altered to be more privacy enhancing (History, etc). Congratulations to all involved. It is great work. Bernard On 17 Jun 2013, at 17:02, Michael Carbone wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Congratulations Tor devs! Serious kudos -- this is exactly the > direction TBB needs to go. > > A couple minor things: the order of the addons in the toolbar seems > arbitrary (particularly the location of the Tor button, NoScript, and > HTTPS Everywhere). I'm sure it's not, but at minimum it might be good > in the about:tor splash page to have an arrow pointing to the location > of the TorButton in the toolbar if folks need to change settings. > Also, the search button image in about:tor is pixelated. > > This is a huge step forward in UX, very exciting! > > Michael > > On 06/17/2013 09:45 AM, Jacob Appelbaum wrote: >> Hi, >> >> I'm really excited to say that Tor Browser has had some really >> important changes. Mike Perry has really outdone himself - from >> deterministic builds that allow us to verify that he is honest to >> actually having serious usability improvements. I really mean it - >> the new TBB is actually awesome. It is blazing fast, it no longer >> has the sometimes confusing Vidalia UI, it is now fast to start, it >> now has a really nice splash screen, it has a setup wizard - you >> name it - nearly everything that people found difficult has been >> removed, replaced or improved. Hooray for Mike Perry and all that >> helped him! >> >> Here is Mike's email: >> >> https://lists.torproject.org/pipermail/tor-talk/2013-June/028440.html >> >> Here is the place to download it: >> >> https://people.torproject.org/~mikeperry/tbb-3.0alpha1-builds/official/ >> >> Please test it and please please tell us how we might improve it! - -------------------------------------- Bernard / bluboxthief / ei8fdb IO91XM / www.ei8fdb.org -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJRv4OOAAoJENsz1IO7MIrrCcQH/iic0Jy+xpAfFTXs29cxuQV2 Lcw/Im2uxxxwapQGK3+7hGWkfynwG+O/CvyN/RaFbCx6a2GywS8D++SAhSEpCVyL GMA6Vx8ZqiJ5KoqQkQ2Y2ENCMLkGIxgD374+bfSkHS5wkSmBesV2/DMva96PxO9e KZT9qZve/OwlXgsCKA0Z1CuHxPpxrbC9htNpRSJ31GUjNv+jZc6OIhDdAEbayx2W IBlgtsrb+glRe5gl1cRaBej3fnn6/zFoVoOMTQhwQEQr6xo8bvQUEcyNsHjMS6gW J6c3hSGcMmUnesvYCOv/x5BXGvC0FQBHHpk4+jh3zNeU3VAik59BLiVQ7e1PCL0= =ad2Q -----END PGP SIGNATURE-----

1 0

difference between cached-descriptors and cached-consensus
by moataz ahmed 16 Jun '13

16 Jun '13

I have one question please what is the difference between cached-descriptors and cached-consensus Best Regards Moataz Ahmed,

2 1

Torsocks locking design
by David Goulet 16 Jun '13

16 Jun '13

Hi everyone, I'm posting here the small design document I've made for the Torsocks locking mechanism. I'm looking for reviews, comments, improvements, ... well anything useful! :). (Even English mistakes since it's not my primary language). Future changes will be pushed here if any are needed after this thread is done with. https://github.com/dgoulet/torsocks/blob/rewrite/doc/proposals/01-Thread-sa… Thanks people! David

2 2

TBB check sums
by Linus Nordberg 15 Jun '13

15 Jun '13

Hi, I've built TBB's using the new and shiny gitian thing. Thank you Mike Perry for putting lots of effort into this! I'm at commit f4869b0b (tor-browser-bundle.git). Check sums below. --8<---------------cut here---------------start------------->8--- user@host:~/usr/src/tor-browser-bundle/gitian$ sha256sum TorBrowserBundle-3.0-alpha-1-osx32_* tor-browser-linux* torbrowser-install-3.0-alpha-1_* 1f3265462f267c30bf9bf8a8ac41904f03166f49ce78ed1c88e16915bf644313 TorBrowserBundle-3.0-alpha-1-osx32_de.zip f588f5ffebea4fce1ecac7d4c694b94afd202e0d82fbf6a19e153c8e9c8e8f12 TorBrowserBundle-3.0-alpha-1-osx32_en-US.zip d7067a2eae9b1899e854aa1083653b452ed33137139ed94807651c208b17da33 TorBrowserBundle-3.0-alpha-1-osx32_es-ES.zip 372d9790ca6be27f617afb97ad7923d46f8b823935375ce3262abd09af6038ab TorBrowserBundle-3.0-alpha-1-osx32_fa.zip dfd614b35d00a2ac9f5d5196bd4f0064fc53a43e909e32cbc847b42121463c85 TorBrowserBundle-3.0-alpha-1-osx32_fr.zip 735bd35612a756e28d011d61c5d682be4305d33db8f48b6e8721ff40c0784e7b TorBrowserBundle-3.0-alpha-1-osx32_it.zip cf38210e03a64bec93e94a8c28bb9b3e3462f4588d816515a10a22ef39126392 TorBrowserBundle-3.0-alpha-1-osx32_ko.zip fe3f355972b5712d9084ddb3f6926bf86910a4e0613d701523d35ae1a8591d00 TorBrowserBundle-3.0-alpha-1-osx32_nl.zip 81bd77b6e446aa2eb0cf1969dbad80923ebc26fcf55f3153fb1f2fcf4a554cae TorBrowserBundle-3.0-alpha-1-osx32_pl.zip 008e1eeb8ecd6f7f0e8543943eba1d40764a7b33edff06ccf4cf87de5ac74424 TorBrowserBundle-3.0-alpha-1-osx32_pt-PT.zip df47cd6c8167e7a610df586d69c0e6e7368c904e0e42ff0186c2831932338db1 TorBrowserBundle-3.0-alpha-1-osx32_ru.zip c9af80e798824ce1154cbf32ef1ba30f1a6e7b7e682e285dc69a2aaeada7bfa2 TorBrowserBundle-3.0-alpha-1-osx32_vi.zip ae47dd903c7683db89d769b8fb26cc0df8ebede424af09aa1108d773a808bf11 TorBrowserBundle-3.0-alpha-1-osx32_zh-CN.zip c6de2a39100be02f806a820196d87c565225cfbd637754f23206463eab1b96d5 tor-browser-linux32-3.0-alpha-1_de.tar.xz d28f7e708f01fb522e4a13d987859ace98cbe0f18ec3de71391c0fd3a82a527a tor-browser-linux32-3.0-alpha-1_en-US.tar.xz 74ac8e1b3d86148d3f94fdc5c21636859b07339bec00da68bf5a15a12b4b3b45 tor-browser-linux32-3.0-alpha-1_es-ES.tar.xz e4d575f89de04c955981923e467e879cdf5f6c2ac36a0d984058d0f16bdc3cd7 tor-browser-linux32-3.0-alpha-1_fa.tar.xz 5a39818f665906b2542568329c0f859264057b9c8df21d78b0f2b34d8bdfd35e tor-browser-linux32-3.0-alpha-1_fr.tar.xz 7f59ac51056e0d933027c57b032dc4896bca61d0f464bb28f3eff1dc46c1d58c tor-browser-linux32-3.0-alpha-1_it.tar.xz f9fc3d164f79e44fd1d43d15f59ccd56175d7d18a413b18ac1abe15adbc34662 tor-browser-linux32-3.0-alpha-1_ko.tar.xz 52d9401edc032d833500bafed3e7ae277365429c6e1d9293dfa6a88132a4b0b2 tor-browser-linux32-3.0-alpha-1_nl.tar.xz 52218f2d8f0d7192ed832087ef2fa1a6cb013117e887467965875c04752d7b6f tor-browser-linux32-3.0-alpha-1_pl.tar.xz dc201b5e9c9cac0883924b8558d3f317c10136107bded636722762030316acbe tor-browser-linux32-3.0-alpha-1_pt-PT.tar.xz 4be1e6b43d55bc3ef1d4d5db360ec6b9981d6ea7e5be7c19b9d8ed81e4f72b77 tor-browser-linux32-3.0-alpha-1_ru.tar.xz 057aebd3ad07d6edd661c314102459fb97377074a06b7e68035b00be4ab948ed tor-browser-linux32-3.0-alpha-1_vi.tar.xz f79c46aa4f52000faffe32ed1a8e10b82c481861fcd131bed2eeccb5078c1df2 tor-browser-linux32-3.0-alpha-1_zh-CN.tar.xz 763a96564571c364f73c1046465c6745b2bb150f914ab2740639d779da2529cb tor-browser-linux64-3.0-alpha-1_de.tar.xz 5e5dd31612df58f2cfb870e4169c48b2578b4eb0beaee6c391189ba82e4584d5 tor-browser-linux64-3.0-alpha-1_en-US.tar.xz abc771efa43b62d3f7055528913622e1c657acb20dbdfcfebabcf25b16f20a4b tor-browser-linux64-3.0-alpha-1_es-ES.tar.xz fe9a7905073089870d7f19857d9bc1e1d7e508ea283519ddb9abd24d6b6a0d6f tor-browser-linux64-3.0-alpha-1_fa.tar.xz bc2849260e716c5e4cab7e7e157f6cf2bbea93533c5692f466bce964bff25677 tor-browser-linux64-3.0-alpha-1_fr.tar.xz 6564a05774a602557af3eb3ffbedbb542c0d966a69ee8997be56eb1ab0a02c0c tor-browser-linux64-3.0-alpha-1_it.tar.xz d92f5d527e7aa48cbe500b84e8d1c69da0a716329f2b3203fdd2d5aacb8e5856 tor-browser-linux64-3.0-alpha-1_ko.tar.xz 81dddc65e0534902d7c1a7f39f4235e9d11e449d75647555c1ca4c04625eea63 tor-browser-linux64-3.0-alpha-1_nl.tar.xz 5b678842584503a6ddd6e40c7759ff14b0d87ca9f1a6721b2c6a10355ef97e35 tor-browser-linux64-3.0-alpha-1_pl.tar.xz 3df16ccf393169d8057d11ec4d85cb2940ddfb7f65c37c2607870f9c16b28efa tor-browser-linux64-3.0-alpha-1_pt-PT.tar.xz 371777984b02897f25b6515b61db22b9fbfa0c78d253d19fc5aade754a26c74b tor-browser-linux64-3.0-alpha-1_ru.tar.xz cfc4118a8345a8226c4638ad4719a7b12e5d3efd7faf5d8575fd2b341d510956 tor-browser-linux64-3.0-alpha-1_vi.tar.xz a49a8906e0f3013e2e02c41b68bde961d25100c1a27a8a497f5cd2bcb8764c27 tor-browser-linux64-3.0-alpha-1_zh-CN.tar.xz 951ae9027cb398e7721f9fff2af357c032316b64738bf7867035dc4697da8f3a torbrowser-install-3.0-alpha-1_de.exe c0d17168b2e2c8d9d8762da62f207d3660494cb0fe4879217db0c2902a553abb torbrowser-install-3.0-alpha-1_en-US.exe ab219b4f862aa86fedeadfde723158c5c2d4d84514d91b9fa6012d3b90c95646 torbrowser-install-3.0-alpha-1_es-ES.exe f8047706446d1dc112768edd01f1af246b1b57408b307d19996b39ffeaaba452 torbrowser-install-3.0-alpha-1_fa.exe 22e2b4d76df62185f3d011bf061cb75b173a0171c8198f21baff66ccde2905e2 torbrowser-install-3.0-alpha-1_fr.exe 370aea69718e443d3ede77d772ebb1ec2a0517e3d8b9f68573fa70dd9871a208 torbrowser-install-3.0-alpha-1_it.exe ad2032d82862177fd9e07a0aa9b65720a6f4817322760de44db9fcd84d016f50 torbrowser-install-3.0-alpha-1_ko.exe 29c72de44e65a6f5f0ee83ba79e5db13d430e2d7dda244528d16f540ad1db21f torbrowser-install-3.0-alpha-1_nl.exe bd524c8dce296db2c1f9c09b024886faffc28bf4407526b2f310fdf66459faed torbrowser-install-3.0-alpha-1_pl.exe 178f87dad198a565b13a419e5d10eabd760e09feb9e892d5d0baf6259fed3f58 torbrowser-install-3.0-alpha-1_pt-PT.exe d803200c16e17f8165463e416d5d043d1edcd9a564b9734f7c83feed8c2d55d1 torbrowser-install-3.0-alpha-1_ru.exe f623e459eb4579a6de1e2014cfdfcd2059b78d16fafb6d8e3873ab26d0e8bda0 torbrowser-install-3.0-alpha-1_vi.exe c888e325784048067698b59c9db0798fba23a83b53cc645ad6d83f7b1abf3f57 torbrowser-install-3.0-alpha-1_zh-CN.exe --8<---------------cut here---------------end--------------->8---

2 1

Torsocks reengineered
by David Goulet 14 Jun '13

14 Jun '13

Hi everyone, About a week ago I've sent an email to the Torsocks maintainers to address some concerns I had about important issues of the current code base. For the reasons found below, I proposed a rewrite that I am willing to do and submit it to the community once I feel ok with it. After some back and forth, the consensus was that I should go ahead and do it. Best case scenario, I come up with a tested library that has a smaller set of problems (hopefully) and could eventually be considered to replace the current version. Worst case, I lose my time :). Now, I'm not looking to do that alone in my corner or anything, what I want is this effort to be as open as possible for everyone that want to help, contribute or/and follow it. Some help would be really appreciated for the compat. part (Windows, OS X, BSD, etc...). Here is the repository I've created and started working on the rewrite. It has been branched from upstream master at commit e0bf65b5d3ca0e28b827c08d80b0fe1841d5a149 https://github.com/dgoulet/torsocks/tree/rewrite There might be some rebasing going on in that branch in the next weeks so please don't consider it right now as "git stable" since I'm in the heavy part of getting everything together before starting a "normally growing" master branch. If you like to contribute or help, let me know and we'll make something work. Big thanks to nickm, ioerror and sysrqb for their help on all this. Cheers! David Torsocks rewrite reasons: --------------- (You can see that as either we put in 2000 lines of code to fix it in a ~3000 lines repository or we start fresh with some key aspect, maintainability and security in mind.) Code and Maintenance Issues: 1) The code needs to be easier to maintain, so that it isn't sporadically maintained. Considering the number of issues (see below), it needs more love on a regular basis right now. 2) It has never been safe from the start so a rewrite will NOT impact the current state of security. There is not much tests right now. 3) Small code base. Fix it clean before it gets too big. 4) One of the biggest technical issues is that it's not thread safe and fixing it right now would add an important impact on performance adding locks to multiple global data structures. A clean rewrite would allow to take into account this *very* important feature from the start without any ugly hacks in the current code base. 5) This is a very, and I can't stress this enough, _VERY_ intrusive library so extra care MUST be put in making it bullet proof in terms of error handling. Right now, there is multiple call sites that can fail on error. 6) There is not even close to enough tests, thus not loosing that stable portion of a project. 7) No compatibility layer is present for multiple OS and architecture. 8) FD passing through Unix socket support. * Should at least be detected and notify the user or even deny execution since the process receiving the socket is not under torsocks control. 9) Symbol name space polluted. (should all be prefixed). 10) Libc hijacked calls of torsocks don't return correct values in error path. * This is bad because for instance the caller expect errno to be set and makes decision upon that value that MUST be right once returned. There is multiple call sites that are problematic. 11) IPv6 support. ----------------

7 11

Tor over Open Garden mesh network
by Paige Peterson 13 Jun '13

13 Jun '13

Hello all, I was recommended to join this group after emailing the general help address with the following message: I am the Community Manager for Open Garden <https://opengarden.com>, a p2p mesh networking application for phones, tablets and laptops. Currently, Tor doesn't work over Open Garden and when talking to my lead developer about it a while ago, he said that Tor would need to support an upstream proxy - which he can't find any documentation on. Some users of Open Garden have requested the ability to use Tor over the Open Garden protocol and as the Community Manager, I am attempting to understand whether or not this is feasible to implement. If there is any light that can be shed from your side as to what would need to happen to support each other, then please enlighten me! If it would be more productive to have a conversation with our lead developer, then I can ask him to join the list as well. Thanks for your time! -- Paige Peterson Open Garden Community Manager forum.opengarden.com

2 2

Building better pluggable transports - GSoC 2013 project
by Chang Lan 11 Jun '13

11 Jun '13

Hello everyone! I am a Tor GSoC student who will be working on the pluggable transports this summer. My mentor is Steven and my co-mentor is George Kadianakis. It is great to be part of the Tor community! Steven already kicked off the discussion about how to build better transports. The original project proposal[1] discussed the possibility of sending data over UDP with extra efforts to guarantee reliable in-order delivery. However, as George mentioned recently[3], ScrambleSuite[2] may already solve the issue of scanning resistance. Given that ScrambleSuite is being deployed, improving protocol obfuscation will be my main focus. HTTP impersonation is really useful, since there are numerous HTTP proxy outside the censored region, while the number of bridges is quite limited. What I'm gonna be doing during the summer is implementing a good enough HTTP impersonation based on pluggable transports specification. There are still many open questions indeed. Discussions are more than welcome! I'll be keeping my GSoC log here: http://changlan.github.io/obfsproxy I'm also available #tor-dev@oftc with the handle "clan", feel free to ping me there! [1]: http://changlan.info/gsoc.html [2]: http://www.cs.kau.se/philwint/scramblesuit/ [3]: https://www.google-melange.com/gsoc/proposal/review/google/gsoc2013/changla… Cheers, Chang

5 6

Help Wanted: Evaluate our Tool for (privacy-preserving) Automated Debugging
by Christian Grothoff 11 Jun '13

11 Jun '13

Hi! Collecting good bug reports from users is a challenge, as most users are unable (or unwilling) to inspect problems in depth. Existing tools to automatically report program failures are often problematic as they either produce superficial reports or are prone to leaking private information (i.e. by including a full snapshot of the process address space in the form of a core dump). At TUM, we are developing Monkey[1], a free software tool that automatically generates high-quality privacy-preserving bug reports (for C code) which we hope to use for GNUnet and Tor eventually. (It runs with GNUnet and Tor already, but might need more work prior to real-world use.) We have reproduced and analyzed a set of real-world bugs using the system and would now like to study how well developers can find the bugs using the extracted information. Please participate in our public "survey" (or rather, experiment) where we measure your performance at identifying bugs based on crash reports collected via different methods, including traditional stack traces, core dumps (accessed via a live gdb session) and of course Monkey. So if you can spare the time, please help our efforts by participating in our survey[1] and passing the link to your colleagues and friends. (Who finds more bugs faster?) [0]: https://gnunet.org/monkey/ [1]: https://gnunet.org/monkey/survey/index.php/943594?lang=en Happy hacking! Christian Grothoff & Markus Teich p.s.: We'll be happy to talk with you about Monkey at the Tor developer meeting in Munich; however, Markus's thesis deadline is earlier...

1 0

Re: [tor-dev] grabbing Tor circuit (node) data- Tor stem, torrc and Tor control port
by Damian Johnson 11 Jun '13

11 Jun '13

Hi Sarah. I'm not really sure what you're trying to ask in most of these questions. Assuming that your goal is simply 'I want to connect to port 9051 and dump information about all the relays I'm presently using in my circuits' then the following should do the trick. Take the following with a grain of salt - I just wrote it, I haven't tried running it. Should be close though. ;) from stem.control import Controller with Controller.from_port(port = 9051) as controller: my_relay_fingerprints = [] # fingerprints of all relays in our circuits for circ in controller.get_circuits(): my_relay_fingerprints += [fp for (fp, nickname) in circ.path] for fingerprint in my_relay_fingerprints: desc = controller.get_network_status(fingerprint) country = controller.get_info("ip-to-country/%s" % desc.address, "unknown") print "relay: %s:" % fingerprint print " address: %s:%s" % (desc.address, desc.or_port) print " locale: %s" % country Did you have any other questions? On Mon, Jun 10, 2013 at 9:43 AM, SARAH CORTES <sarah(a)lewis.is> wrote: > Damian, thanks, this is very helpful. > > is there a way to do this in torrc? Else, i suppose i will need to: > > 1) create a socket or connection to my port 9051 ; do i need/can i use > TORRC_CONTROL_SOCKET ? > 2) call get_circuits() ; grab the relay fingerprints > Do I need circuit = controller.get_circuit(circ_id) > 3) return class:`stem.events.CircuitEvent` ; for the given circuit > Not sure whether or where to use the "path" attribute > 4) call controller.get_network_status() to get IP address, nickname, ORPort, > Should I use: > desc_by_fingerprint = controller.get_network_status(test_relay.fingerprint) > > + desc_by_nickname = > controller.get_network_status(test_relay.nickname) > > 5) use Maxmind- i already have the GeoIPLite DB to grab AS and country, and > onion code also from Arturo > > > Any guidance is appreciated > > > https://lists.torproject.org/pipermail/tor-commits/2012-December/051174.html > > get_circuit(self, circuit_id, default = UNDEFINED): > + """ > + Provides a circuit presently available from tor. > + > + :param int circuit_id: circuit to be fetched > + :param object default: response if the query fails > + > + :returns: :class:`stem.events.CircuitEvent` for the given circuit > + > + :raises: > + * :class:`stem.ControllerError` if the call fails > + * ValueError if the circuit doesn't exist > + > + An exception is only raised if we weren't provided a default > response. > + """ > + > + try: > + for circ in self.get_circuits(): > + if circ.id == circuit_id: > + return circ > + > + raise ValueError("Tor presently does not have a circuit with the id > of '%s'" % circuit_id) > + except Exception, exc: > + if default: return default > + else: raise exc > + > def get_circuits(self): > """ > Provides the list of circuits Tor is currently handling. > > > > On Jun 10, 2013, at 10:34 AM, Damian Johnson <atagar(a)torproject.org> wrote: > > Hi, Damian, thanks. I am happy to discuss it on tor-dev@. But I want to keep > off spam, which some of my questions at first may be, essentially Qs. But, > if you think they would be of interest to tor-dev, or others could help, > just let me know, and i will sign up for it. > > > They certainly are! If you're interested in tor and development then I > would definitely suggest being on that list. Including it for this > thread. > > I am trying to figure out how to pull in the nodes that are actually used in > my Tor circuits. They are the nodes reflected in the Network map function. > > > You want the get_circuits() method. As you mentioned the 'path' > attribute has the relays in your present circuits... > > https://stem.torproject.org/api/control.html#stem.control.Controller.get_ci… > > I have created a MySql DB of some of my Tor circuits and nodes which i am > analyzing. I grabbed 48 circuits with their 144 nodes and info (IP address, > nickname, country) manually from my laptop's Tor network map. > > > That certainly sounds painful. The circuit paths will provide the > relay fingerprints which you can use for get_network_status() to get > the address, nickname, ORPort, etc... > > https://stem.torproject.org/api/control.html#stem.control.Controller.get_ne… > > As for locales that would be done via get_info('ip-to-country/<address>')... > > https://gitweb.torproject.org/torspec.git/blob/HEAD:/control-spec.txt#l672 > > ... and ultimately to AS and country. > > > AS will require the Maxmind AS database or something else. I know that > Onionoo includes the AS information so the options that come to mind > are either to (a) see how it does it or (b) query Onionoo for this > information. > > https://onionoo.torproject.org/ > > And i have read much of the control-spec, don't know how much is out of date > > > The control-spec should be up to date. If there are any inaccuracies > then please let us know! > > Did you have any other questions? -Damian > > On Mon, Jun 10, 2013 at 4:44 AM, SARAH CORTES <sarah(a)lewis.is> wrote: > > Hi, Damian, thanks. I am happy to discuss it on tor-dev@. But I want to keep > off spam, which some of my questions at first may be, essentially Qs. But, > if you think they would be of interest to tor-dev, or others could help, > just let me know, and i will sign up for it. > > For example, I am trying to figure out how to pull in the nodes that are > actually used in my Tor circuits. They are the nodes reflected in the > Network map function. I have read your fine stem tutorials, it is so > impressive you have dome so much work and documentation on your own > initiative. It is certainly a huge help to me and otter researchers like me. > > I have created a MySql DB of some of my Tor circuits and nodes which i am > analyzing. I grabbed 48 circuits with their 144 nodes and info (IP address, > nickname, country) manually from my laptop's Tor network map. I am analyzing > their country, so I am seeking to map nickname or fingerprint of the node to > IP address and ultimately to AS and country. Ultimately, I am analyzing > jurisdictional arbitrage and the hostility factors of differ countries to > Tor traffic, and whether it is possible to incorporate country or AS in to > the Tor path algorithm. > > I can see the entry guard nicknames and fingerprints in my state file and > pick them up there, if necessary. Wish i could just edit the logs to display > all nodes, then figure out how to map the node fingerprint or nickname to > its IP address them AS and country. I understand there is a Tor atlas > function but have not read it carefully yet. > > I have read documentation on the contents of the consensus file, the > descriptors, geoip and state files, and played around with them a bit to > understand them. I grasp that a fingerprint is a hash of the node's public > key, and one or both of which seem to be the most reliable ID for a node. > > I can see from your documentation that variable path(nickname, fingerprint) > contains the data i want. Just need to be able to get that data easily. Not > sure if editing my torrc file is the way or what. If you have any > suggestions, they are much appreciated. > > And i have read much of the control-spec, don't know how much is out of date > https://gitweb.torproject.org/torspec.git/blob/HEAD:/control-spec.txt > > I have read this on modifying torrc, and played around with modifying torrc, > on an elementary basis: > https://www.torproject.org/docs/faq.html.en#torrc > > and some tickets on modifying torrc > https://trac.torproject.org/projects/tor/ticket/6147 > > and what I believe is your excellent documentation on stem events; > https://stem.torproject.org/api/response.html#stem.response.events.Bandwidt… > > > > > > > > On Jun 8, 2013, at 2:31 PM, Damian Johnson <atagar(a)torproject.org> wrote: > > Hi Sarah. Yup, I'd be more than happy to help if you have any stem > questions. Email would definitely be better since we look to keep > missing each other on irc. I'd appreciate it though if we discussed it > on the tor-dev@ email list... > > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev > > On Sat, Jun 8, 2013 at 3:42 AM, SARAH CORTES <sarah(a)lewis.is> wrote: > > Hi Damian, I'm Sarah Cortes, a researcher. I tried you on irc on #tor-dev > but was unable to reach you. We met at the tor dev meeting which i attended > in March. I have some Qs for you regarding stem. Please let me know if you > are available, thanks > > >

2 1

traversing the source code of tor
by H S 10 Jun '13

10 Jun '13

Hi there, We would like to implement some specific protocol in Tor as an implementation project. Our one of pseudo codes that we have to take into account is the one mentioned on the paper under the link http://www.cypherpunks.ca/~iang/pubs/UC-OR.pdf , page 5, figure 2. I would like to know how can I connect or relate this pseudo code with the Tor source code to help us understand where we should insert our desired modification on the source code of the Tor. For instance in the first of the pseudo code line we have "upon an input (setup):". And know in which file/lines of the Tor source code we have this?

2 1

Re: [tor-dev] stem
by Damian Johnson 10 Jun '13

10 Jun '13

> Hi, Damian, thanks. I am happy to discuss it on tor-dev@. But I want to keep > off spam, which some of my questions at first may be, essentially Qs. But, > if you think they would be of interest to tor-dev, or others could help, > just let me know, and i will sign up for it. They certainly are! If you're interested in tor and development then I would definitely suggest being on that list. Including it for this thread. > I am trying to figure out how to pull in the nodes that are actually used in > my Tor circuits. They are the nodes reflected in the Network map function. You want the get_circuits() method. As you mentioned the 'path' attribute has the relays in your present circuits... https://stem.torproject.org/api/control.html#stem.control.Controller.get_ci… > I have created a MySql DB of some of my Tor circuits and nodes which i am > analyzing. I grabbed 48 circuits with their 144 nodes and info (IP address, > nickname, country) manually from my laptop's Tor network map. That certainly sounds painful. The circuit paths will provide the relay fingerprints which you can use for get_network_status() to get the address, nickname, ORPort, etc... https://stem.torproject.org/api/control.html#stem.control.Controller.get_ne… As for locales that would be done via get_info('ip-to-country/<address>')... https://gitweb.torproject.org/torspec.git/blob/HEAD:/control-spec.txt#l672 > ... and ultimately to AS and country. AS will require the Maxmind AS database or something else. I know that Onionoo includes the AS information so the options that come to mind are either to (a) see how it does it or (b) query Onionoo for this information. https://onionoo.torproject.org/ > And i have read much of the control-spec, don't know how much is out of date The control-spec should be up to date. If there are any inaccuracies then please let us know! Did you have any other questions? -Damian On Mon, Jun 10, 2013 at 4:44 AM, SARAH CORTES <sarah(a)lewis.is> wrote: > Hi, Damian, thanks. I am happy to discuss it on tor-dev@. But I want to keep > off spam, which some of my questions at first may be, essentially Qs. But, > if you think they would be of interest to tor-dev, or others could help, > just let me know, and i will sign up for it. > > For example, I am trying to figure out how to pull in the nodes that are > actually used in my Tor circuits. They are the nodes reflected in the > Network map function. I have read your fine stem tutorials, it is so > impressive you have dome so much work and documentation on your own > initiative. It is certainly a huge help to me and otter researchers like me. > > I have created a MySql DB of some of my Tor circuits and nodes which i am > analyzing. I grabbed 48 circuits with their 144 nodes and info (IP address, > nickname, country) manually from my laptop's Tor network map. I am analyzing > their country, so I am seeking to map nickname or fingerprint of the node to > IP address and ultimately to AS and country. Ultimately, I am analyzing > jurisdictional arbitrage and the hostility factors of differ countries to > Tor traffic, and whether it is possible to incorporate country or AS in to > the Tor path algorithm. > > I can see the entry guard nicknames and fingerprints in my state file and > pick them up there, if necessary. Wish i could just edit the logs to display > all nodes, then figure out how to map the node fingerprint or nickname to > its IP address them AS and country. I understand there is a Tor atlas > function but have not read it carefully yet. > > I have read documentation on the contents of the consensus file, the > descriptors, geoip and state files, and played around with them a bit to > understand them. I grasp that a fingerprint is a hash of the node's public > key, and one or both of which seem to be the most reliable ID for a node. > > I can see from your documentation that variable path(nickname, fingerprint) > contains the data i want. Just need to be able to get that data easily. Not > sure if editing my torrc file is the way or what. If you have any > suggestions, they are much appreciated. > > And i have read much of the control-spec, don't know how much is out of date > https://gitweb.torproject.org/torspec.git/blob/HEAD:/control-spec.txt > > I have read this on modifying torrc, and played around with modifying torrc, > on an elementary basis: > https://www.torproject.org/docs/faq.html.en#torrc > > and some tickets on modifying torrc > https://trac.torproject.org/projects/tor/ticket/6147 > > and what I believe is your excellent documentation on stem events; > https://stem.torproject.org/api/response.html#stem.response.events.Bandwidt… > > > > > > > > On Jun 8, 2013, at 2:31 PM, Damian Johnson <atagar(a)torproject.org> wrote: > > Hi Sarah. Yup, I'd be more than happy to help if you have any stem > questions. Email would definitely be better since we look to keep > missing each other on irc. I'd appreciate it though if we discussed it > on the tor-dev@ email list... > > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev > > On Sat, Jun 8, 2013 at 3:42 AM, SARAH CORTES <sarah(a)lewis.is> wrote: > > Hi Damian, I'm Sarah Cortes, a researcher. I tried you on irc on #tor-dev > but was unable to reach you. We met at the tor dev meeting which i attended > in March. I have some Qs for you regarding stem. Please let me know if you > are available, thanks > >

2 1

Gitian-based Deterministic Build System for TBB (Need MacOS Help!)
by Mike Perry 10 Jun '13

10 Jun '13

Over the past couple weeks I've been redoing the TBB build system to use Gitian to produce alpha TBBs using Tor Launcher instead of Vidalia. I have succeeded in producing deterministic, localized builds of TBB for Linux and Windows. This means that independent people all over the world can now easily produce their own bundles for these platforms fresh from sources, and have their bundles exactly match the bundles the Tor Project releases, down to the SHA256 hash. If we leverage this property wisely, it will allow us to defend against targeted attacks against our bundlers and their build machines, and even ultimately ensure the integrity of our bundles in the event of key compromise of the gpg keys used to sign the bundles. My plan for this is for there to be between 2-3 official signers for each bundle, where each person produces their build independently, and signs the (identical) result files. To further protect against targeted attack, in addition to these 2-3 official signers, we need some people to be "secret verifiers". Ideally these people would not be publicly affiliated with the Tor Project, but would still produce their own bundles anyway. If their SHA256 ever fails to match the signed bundles, that person should anonymously open a trac ticket (using the cypherpunks account) and attach the bundle files that differ for analysis. The differing files can be found easily enough with 'diff -r'. To ensure the existence of these "secret verifiers", I believe that the official signers should occasionally conspire to conduct "Fire Drills", where they all agree to alter the bundle in some innocuous way (such as adding whitespace to a config file or a Firefox JS file), and ensure that a verifiers anonymously report the verification failure. In future versions of Tor, we should probably add a consensus field consisting of a url to a file that lists the current recommended bundle hashes and versions, along with the current SHA256 of that file, to anchor the bundle authentication the Tor's current trust root (the 9 dirauth keys). To try out the new build system, please see the README, and let me know where the system could use clarification or improvement to make it easier to use: https://gitweb.torproject.org/builders/tor-browser-bundle.git/blob/HEAD:/gi… The build system has some quirks that are worth mentioning: 1. It requires you run it from either an Ubuntu 12.04 or above host with KVM support, *or* you run it from an Ubuntu 12.04 or above chroot/VM. The bundle scripts try to detect your current situation and suggest that you "export USE_LXC=1" from your shell if you need to, to cause the system to use LXC instead of KVM (so that you can build from an Ubuntu VM or on a machine that does not otherwise support KVM). 2. We currently have no MacOS support. To support MacOS, we need to create cross-compilers for it so that we can produce builds from the Gitian VMs (which again are Ubuntu). A few people have done this. I have sent them mail asking for instructions on how to reproduce their compiler packages: http://www.tarnyko.net/en/?q=node/9 https://launchpad.net/~flosoft/+archive/cross-apple/+packages http://wiki.freepascal.org/Cross_compiling_OSX_on_Linux Unfortunately, at least one of those URLs say that to produce a cross-compiler, you need access to an OSX SDK. Since I do not have a Mac that is currently supported by recent OSX SDKs, and since we *really* want to be sure that the cross-compilers we produce use code from a fresh known-good SDK install, I won't be doing this. Please let me know if you'd like to help tackle this problem. In the meantime, I am going to work on the rest of the "Short Term" TODO items, and produce official alpha bundles for Linux and Windows, so we can test Tor Launcher in an official alpha release. Here's the TODO file: https://gitweb.torproject.org/builders/tor-browser-bundle.git/blob/HEAD:/gi… Happy building! -- Mike Perry

3 6

Academic Project Guidance
by mahesh 09 Jun '13

09 Jun '13

Hi, I am final year undergraduate student at Pune Institute Of Computer Technology, Pune, India. I have to do a academic project in span of 6-months with other three students.I am looking for a mentor who would discuss ideas with us and provide proper guidance. Also I am also interested under working an organization's guidance. Please interested people let me know. Sincerely, Mahesh

1 0

Format-Transforming Encryption Pluggable Transport
by Kevin P Dyer 09 Jun '13

09 Jun '13

Last September I announced initial results [1] towards a framework, which we call Format-Transforming Encryption (FTE), for encoding messages using regular languages. We're excited to announce that we've made progress towards an implementation and would like to invite alpha testers. Our source code is available on github [2]. Tor Bundles are available for OSX/Linux [3] that include our FTE framework and are configured by default to work with FTE+Tor bridges deployed in the United States. Unfortunately we don't, yet, support Windows. The latest version of our paper is available on the Cryptology ePrint Archive [4]. In the paper we describe our framework and provide a comprehensive security evaluation of FTE's success in evading six DPI systems --- including using regular expressions from open-source DPI systems to evade detection by a closed-source black-box commercial DPI system. By "evade" we mean that it's easy for FTE to tunnel arbitrary TCP streams (e.g., Tor) such that they are (mis)classified by DPI systems as a configurable target protocol (e.g., HTTP, SMB, RTSP, etc.) of one's choosing. We release FTE in its alpha stage because we believe it is well positioned to evade the suspected protocol white-listing [5] recently reported in Iran. More generally, we're optimistic FTE has long-term potential as a tool to enable users to control how their traffic is classified by passive DPI systems. As one example, over the last month, we've successfully tunneled Tor through the Great Firewall of China, using FTE to make our traffic "look like" HTTP. We're eager for feedback on this alpha release, so please do not hesitate to contact us with questions. -Kevin P Dyer (and his co-authors) [1] https://lists.torproject.org/pipermail/tor-dev/2012-September/003993.html [2] https://github.com/redjack/FTE [3] https://github.com/redjack/FTE/tree/master/TorBundles [4] http://eprint.iacr.org/2012/494 [5] https://lists.torproject.org/pipermail/tor-dev/2013-May/004787.html

1 0

Pluggable transport bundles with websocket transport
by David Fifield 09 Jun '13

09 Jun '13

I have made new experimental pluggable transports bundles with support for the websocket transport. We hope this transport looks enough like HTTP to get past certain firewall filters. https://people.torproject.org/~dcf/pt-bundle/2.4.12-alpha-2-websocket1/ If the transport name websocket sounds familiar, that's because it's the same transport used by flash proxy. The difference here is that you connect directly to the bridge, rather than going through a browser proxy. The actual software is the websocket-client program from here: https://gitweb.torproject.org/flashproxy.git/tree/HEAD:/websocket-transport Due to a build SNAFU, the OS X packages have the flashproxy transport disabled, with only obfs2, obfs3, and direct websocket enabled. The other platforms have all transports enabled. We would like to have some more fast websocket relays to include in the default torrc in a future release. If you can do this, see the section "How to run a relay" from https://gitweb.torproject.org/flashproxy.git/blob/93be0302:/README#l100 Send the IP address and port of your relay to tor-assistants(a)lists.torproject.org. David Fifield

1 0

Ideas for metrics of the safety of the Tor network
by George Kadianakis 08 Jun '13

08 Jun '13

A year ago or so, during FOCI '12, with the help of some smart people [0] I compiled a list of interesting metrics/visualizations that could help us understand the security of the Tor network. Since even more people are interested in metrics lately, I thought of posting this list here, in case it inspires someone (better than letting it rot unseen). Note that some of the stuff in the list might have been implemented already, and there are also some upcoming academic papers that explore this area. Also, check out https://trac.torproject.org/projects/tor/ticket/6460 In any case, I'm inlining the list: """ 1 Attacker strategy 1.1 Are there certain geographic or network locations where adding relays with a given capacity will most influence your safety metrics? This influence could be positive ("where should I put my relay to best help the Tor network?") or negative ("where should I put my relay to best attack users?"). 1.2 What happens to the network if X relays are compromised? 1.2.1 All Windows relays. 1.2.2 All relays running old Tor versions. 1.2.3 All "top 10% relays" are compromised... 1.3 How much bandwidth do I need to compromise, in order to compromise a random user's path in a given timeframe 1.3.1 Use 'guessing entropy'? 1.4 Is there a difference between compromising a '5Mbit relay' and 'five 1Mbit relays'? Should there be a difference? 1.5 Change classic Tor formula to start considering bandwidth load balancing. 1.5.1 "If an adversary controls m out of n nodes, he can correlate at most (m/n)^2 of the traffic." should consider bandwidth 1.6 See how many exits are exiting on a different IP than the one they accept traffic? (they can sniff twice) 2 Network diversity 2.1 How many relays are running old Tor versions? 2.2 Fraction of paths that have the entry and exit at the same country/AS. 2.3 Fraction of paths that pass twice through AMS-IX/LINX/DE-CIX. 2.4 What happens to the network if we discard relays of certain characteristics? 2.4.1 What happens if we discard the slowest relays? 2.4.2 What happens if we cap the fastest relays? 2.4.3 Discard paths with expected high latency (http://swiki.cc.gatech.edu:8080/ugResearch/uploads/7/ImprovingTor.pdf) 2.5 If only a given fraction of exit relays support IPv6, how much does it reduce your anonymity to be going to an IPv6-only destination? 2.5.1 Should we add a fourth hop, like we do in exit enclaving? 2.6 Is there any relationship between the rate of new relay arrival (e.g. during political events or after popular conferences) and the level of diversity of these relays? 2.7 Graph showing "the X% of the relays see Y% of the traffic" 2.7.1 example, "The 5% of the relays route 55% of the traffic"... 2.7.2 Lorenz Curve / Gini coefficient (Used in "Improving Security and Performance in the Tor Network through Tunable Path Selection") 2.8 Measure router families and how much bandwidth they control/how many circuits they can compromise. 2.9 What is the security difference if families did not exist? 2.10 How much does the /16 subnet restriction influence path selection? 3 Optimization results 3.1 Robustness over time: is an adversary that can knock out X% of the capacity in the network (for various values of X) getting more or less influential as the network grows? How about an adversary who can knock out an absolute capacity of K bytes for various values of K? 3.1.1 Look at the vailability/uptime/whatever of relays and YOU decide which relay has the guard flag. 3.1.2 Is weighted uptime the correct way of assigning a guard flag? Relay with 4 days of uptime gets flag, relay with one day down and three weeks of uptime does not get the guard flag. 3.2 If we give out Guard flags according to some other algorithm, how much safety can we get back? 3.2.1 Safety measures 3.2.2 Alternative guard algorithms 3.3 In Tor 0.2.1.x we started load balancing based on active bandwidth measurements, so we use the bandwidth weights in the network consensus rather than the weights in each relay descriptor. We know that change improved performance, but at what cost to safety? 3.4 What happens to the network diversity if we put a low cap on the bandwidth weighting of any node that hasn't been assigned a measurement by the bandwidth authorities yet, to protect against relays that lie about their bandwidth? If there's no real effect, we should do it; but if there's a large effect, we should find a better plan. 3.5 What if some Tor users choose their paths to optimize a different network property (like latency or jitter), as suggested by Micah Sherr? The infrastructure you've built to measure diversity here should apply there too. 4 Notes 4.1 Modularize the path selection code of pytorctl for researchers to use. 5 Papers to read 5.1 Trust-based Anonymous Communication: Adversary Models and Routing Algorithms 5.2 Latest version of Tariq's "Changing of Guards" paper 5.2.1 Look at "Closed Analysis" section in appendix 5.3 Improving Security and Performance in the Tor Network through Tunable Path Selection 5.4 Metrics for Security and Performance in Low-Latency Anonymity Networks (PDF) (Cached: PDF) """ [0]: the list includes Aaron Johnson, Ian Goldberg, Tariq Elahi, Roger, Nikita Borisov, and more that I can't remember right now.

1 0

Reduce RTT for preemptively built circuits (GSoC)
by ra 08 Jun '13

08 Jun '13

Hello everyone! During this year's Google Summer of Code I[0] will be working on reducing the Round-Trip-Time (RTT) for preemptively built circuits.[1] My mentors are Mike and Aaron. A brief summary of the project: RTTs of circuits can be measured by violating the exit policy of the exit node and the resulting error can be timed in a measuring client. It is assumed that the RTTs are Fréchet-distributed which could be used to reject a preemptively built circuit if its RTT is below a certain threshold value. A basic algorithm will be implemented to gather the required data for further statistical analysis which should help answering open questions like: • Are the RTTs Fréchet-distributed? • Does this strategy make new attacks feasible? • How many probes per circuit are needed to do reasonable estimations? • How much additional load is added to the network? • What is an appropriate cut-off percentile? • Does the strategy work in terms of anonymity and performance? • Does the RTT vary for destination ports? (This might be the case for destination ports that occur rarely in exit policies.) • Does this strategy also work if guard nodes are congested? Best, Robert [0] "ra_" on OFTC [1] http://www.google-melange.com/gsoc/project/google/gsoc2013/ra_/19001

2 1

Censorship Simulator Virtual Machine GSoC
by Arturo Filastò 08 Jun '13

08 Jun '13

Hi Johannes, I wanted to introduce you and your GSoC project to the list. The project is about building a virtual machine based censorship simulator. The goal is to have a way to test if the ooniprobe tests are working properly by simulating the network of a censor. Our goal is to actually run the software that a censor would be running (e.x. squid, bluecoat proxy sg va, etc.) and detect it's presence in an as real as possible environment. Johannes and Klaudiu analyzed a bit of the possible technological solutions to making this here: https://trac.torproject.org/projects/tor/wiki/doc/OONI/CensorshipSimulator. I think that the outcome is that we will be using Vagrant, meaning that this simulator could then be run on OSX, Linux and Windows. The kind of networks we will be creating are those where: * There is a transparent HTTP proxy * There is NAT * Certain sites are blocked thanks to HTTP headers * RST packets are sent when connecting to certain hosts * DNS based censorship is present If you have some ideas of things you would like to see in this, add ideas to this ticket: https://trac.torproject.org/projects/tor/ticket/7233, or create a page in the trac wiki nested under https://trac.torproject.org/projects/tor/wiki/doc/OONI/CensorshipSimulator. ~ Art.

2 1

Creating a p2p identity authentication protocol
by DataPacRat 07 Jun '13

07 Jun '13

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 As suggested by Tor Project's helpdesk, I'm forwarding this message to tor-dev, in hopes that I might be able to evoke any useful references, suggestions or commentary. - ---------- Forwarded message ---------- From: Matt Pagan via RT <help(a)rt.torproject.org> Date: Fri, Jun 7, 2013 at 4:42 PM Subject: [rt.torproject.org #10568] Adapting 'tag' URI into p2p identity authentication system To: datapacrat(a)datapacrat.com You should subscribe to the tor-dev mailing list and bring this up on that public mailing list: https://lists.torproject.org On Fri Jun 07 18:02:44 2013, datapacrat(a)datapacrat.com wrote: > I'm working on the initial stages of a project which seems likely to > be of use to many who use the Tor protocol; and which could itself > likely benefit from the experience of the people who build and use Tor > extensively. > > I am currently looking into creating a new URI based on 'tag:' ( > http://www.taguri.org/ , https://tools.ietf.org/html/rfc4151 ) to use > for distributed reputation systems. I would like a common protocol so > that this idea can be easily expressed: "Authority A says that X and Y > are the same person" (with an optional field for the certainty of that > statement) (with an optional comment field) (with an optional > authentication hash). It seems likely to be simple to implement the > new URI (perhaps called 'nym:') in existing mail/contact software, so > that nym: links can be automatically imported into contact lists to > update them. > > Might you be interested in helping me work this out; or pointing me in > the direction of anyone else who might be? > > > Here's an initial draft of what I mean: > > > nym:Authority[,DateTime]:(Identity1)[,date];(Identity2)[,date][;(Identity3)[,date]][?comment1[&comment2][#authenticationHash] > > While based on 'tag:', there are a number of changes from that URI's > format: > > The authority can be not only an email address or a domain name, but > some other identifier, such as the URL of a social media profile, such > as http://twitter.com/DataPacRat or http://www.facebook.com/DataPacRat > . > > The date is no longer limited just to a particular date, but can be > specified (using ISO 8601 format) down to a particular second, for any > rapidly-changing identities. > > The identities can be plaintext names, social media profile URLs, > library card numbers, or any other chosen identifiers; though > regularly-formed URIs, email addresses, and domain names are most > likely to be most common. > > The comment fields are left incompletely defined, to allow for future > expansion; such as to indiciate trustcloud whuffie scores, how the > authority knows the individual being identified, or anything else that > someone comes up with. It seems a good idea to suggest the use of > existing fields from vCard and FOAF, to ease interoperability. > > By default, if a comment field is a number, that number is assumed to > be how confident the authority is that all the listed identifiers all > refer to the same individual, measured in decibans. (Decibans are > logarithmic, with 0 decibans being equivalent to 1:1 odds, or being > 50% confident; 10 decibans to 10:1 odds, or ~90% confident; 20 > decibans to 100:1 odds, or ~99% confident; and so on.) It is > recommended that these numbers be integers, unless there is a specific > reason to be able to specify confidence to greater accuracy; and with > a magnitude under 128, as it requires extraordinary effort to have 100 > decibans of confidence for even the most fundamental facts. > > (This method also implicitly allows for revocation of an identity > referral, simply by using a negative number instead of a positive > one.) > > The authentication hash is to provide strong evidence that the listed > authority is actually the one making the assertion. By default, it is > assumed to be based on whatever public cryptographic key (eg, > PGP/GnuPG or X.509) is linked to the listed authority ID; and that > what is being signed is the string of text before the hashmark. > > > This could allow for something like the following: > > nym:datapacrat@datapacrat.com:(datapacrat@datapacrat.com),2013-06- > 05;(http://twitter.com/DataPacRat),2013-06-05;(Daniel > Eliot Boese)?100&TrustCloud,774&Klout,29#randomhashofletters > > ... to indicate that as of that particular date, I indicate with > maximum confidence that my name, email address, and Twitter account > all point to me, and that I have two social media scores. (I would > have used 127 decibans instead of 100 if I'd just been asserting my > own identity.) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (MingW32) iQEcBAEBAgAGBQJRskfVAAoJEBrKNlQrJtDDHWoIAKn6wCfrQhinNC6zCvf2D3eS CuSKB0XFPkm903ZwzA29aZKnhC6MJGO78Pu5pUuwZg0oWfB6zJshvmQR9A+QQdif s0Y84iNoeqVHqAqZgCk3sXPxqaNyEU2yEWREr09qNqVmuu6vhxODNInXf46PjV/6 BAlb26Ea75UwZfMpKY7rxYprTkIbkx3/55r16v8bZyKCKEkcb+0QQWf/pXA114eD Ec9YXIBEdPDrrhDOe2hAhJWI3ul3pcf/BK13Ch2ngSp757jxGJrz5QxmGNIu+bgQ Us1SPBS/e8JI9xX2xOa3p/CAh/McxfzFWqPO78t2v77bn/sl45WLfl4RoQ7ulvc= =9XrL -----END PGP SIGNATURE----- Thank you for your time, -- DataPacRat "Then again, I could be wrong."

1 0

Steganography Browser Addon (Google Summer of Code)
by Hareesan 05 Jun '13

05 Jun '13

Hi All, I'm Hareesan, I'm going to work on a browser extension (for firefox) in this summer to detect steganographically and asymmetrically encrypted content embedded in website content such as images, videos , audios and etc. At the same time these addons are caplble of encrypt contents steganographically inside the website contents. Detailed proposal and plans is available on [1]. [1] https://google-melange.appspot.com/gsoc/proposal/review/google/gsoc2013/rha… -- Hareesan R Undergraduate Department of Computer Science And Engineering University Of Moratuwa Sri Lanka

2 2

Moved pluggable transports bundle build scripts
by David Fifield 02 Jun '13

02 Jun '13

I've just moved the build files that were formerly in /flashproxy.git/doc to /pluggable-transports/bundle.git. This is a better place because the pluggable transports bundle doesn't really "belong" to flash proxy--rather the opposite. To build a pluggable transports bundle, follow the instructions in bundle-gnulinux.txt, bundle-macosx.txt, or bundle-windows.txt. In short, once you've set up the environment, you run for example make fetch-gnulinux-i686 make gnulinux-i686 The first command downloads a plain Tor Browser Bundle. The second unpacks the bundle, copies pluggable transports into it, and packs it back up. David Fifield

1 0