- tor-dev - lists.torproject.org

txtorcon 0.11.0
by meejah 16 Aug '14

16 Aug '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 txtorcon 0.11.0 is now released. This adds a few API improvements: * launch_tor() allows access to stdout, stderr in real-time and control whether we kill Tor on and stderr output. See issue #79. * Warning about ``build_circuit`` being called without a guard first is now optional (default is still warn) (from arlolra) * available_tcp_port() now in util (from arlolra) * TorState now has a .routers_by_hash member (from arlolra) You can download the release from PyPI or GitHub (or of course "pip install txtorcon"): https://pypi.python.org/pypi/txtorcon/0.11.0 https://github.com/meejah/txtorcon/releases/tag/v0.11.0 sha256sum reports: 5efb7ba4faf698e68daea3d8711ce0ecfd8b95501cbec00b2093dd99f72dc8cc txtorcon-0.11.0-py2-none-any.whl aa206ab8a31053fd34798659c3d4cd7354a3e6872a86065c55098866df3dcaca txtorcon-0.11.0-py2-none-any.whl.asc ecb7cc8ee002ead5481c17fd62576521862e93081c58d7118f53cf3c8817f857 txtorcon-0.11.0.tar.gz 76ee6983269347d475ff4df9aefb7c43ddd25d24dd67c4e3293f5c8557377652 txtorcon-0.11.0.tar.gz.asc txtorcon 0.10.1 is in Debian, and no doubt this release will migrate there quickly as usual (thanks to Lunar^) thanks, meejah -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEcBAEBAgAGBQJT7vo4AAoJEMJgKAMSgGmnzjsH/36wtSA2Cb1coSuK+5hGNIGa flmGETgEOo4mHRCnSLQdO5JrXAKR9zeEt9tT9IfCTO1kRy4Q5cqzE569RhPsciBn 1g3fMlgXewjJuXx1atefO1sbqQgK74TsIqxkGnK85LEUOcqIcW71JT8lI6CDn3xg LymqLLhbC28uYLot+Y0/KPAME7MAlgugny5Me2sGzey1aKfjZhPXQ6gRJsGVlPjQ qhMD6ck9Xe+QZNkE4udzEzNkvA7Og/HJdwwi3yC/ENKcWKit/9PeKvmttVjyQ9Aj KGeN2CMA5jTHHznvohvAKgeUnkDDR4tqpcoKdJZjCVg9yAaaiNoPw2wj/3O3tTw= =elqw -----END PGP SIGNATURE-----

1 0

Decentralized VOIP over Tor
by terryz＠Safe-mail.net 16 Aug '14

16 Aug '14

Hi, I'm interested an anonymous decentralized VOIP network on Tor. All traffic routed through Tor. Every Tor user being an optional server for PTT or Continuous Speech. How feasible does this sound? --TZ

4 3

Guard nodes and network down events
by George Kadianakis 15 Aug '14

15 Aug '14

Hello friends :) This is a post to discuss how Tor should treat its entry guards when its network goes down. This is part of ticket #12595 [0] which aims to design better interfaces and data structures for entry guards. This thread investigates what should happen when the network goes down and Tor's connection to a guard fails. How should Tor recognize that and connect back to that guard when the network goes up again? I recently sent an email to tor-dev [1] which explains Tor's current behavior and its problems. tl;dr there are edge cases [2] where Tor will not detect the "network back up" event and will connect to low priority guards instead of connecting to its primary guards. The fundamental issue here is that Tor does not have a primitive that detects whether the network is up or down, since any such primitive stands out to a network attacker [3]. This means that when Tor fails to connect to an entry guard, Tor can never be sure whether the guard was actually down or whether the network is down, and that complicates its algorithm significantly. In #12595, I laid down a few different ways that Tor could improve its current "network down" entry guard algorithm [4]. After thinking some more, I've been leaning towards algorithm (a), which is: Everytime we manage to connect to a guard, if it's not the top guard in our list, mark all previous guards as retriable and try again from the top. For me, this seems like the most complete way of ensuring that the guards in the top of the list are always going to get a fair hearing even if the network was down when they were first probed. However, that algorithm is not without its problems. Here are some notes: - This algorithm suffers from an infinite loop. The naive version suffers from an obvious infinite loop if the first guards in our list are actually down. To protect against that, we will probably need to rewrite the algorithm to: Everytime we manage to connect to a guard, if it's not the top guard in our list, mark all previous guards as retriable and try again from the top: this time pick whichever guard we can connect to even if it's not the top one. - This algorithm is not actually robust. If we wanted to design a truly robust algorithm, it would have to be robust even against adversarial "network down" events. That is, the algorithm would need to work well even if you imagine the network as an "on"/"off" switch that the adversary can toggle at will. Here is how that algorithm can fail against such an adversary: 1) Tor starts up. Adversary switches network off. 2) Tor starts going through guards and fails to connect to them. 3) Adversary switches network on. 4) Tor detects "network up" event, marks all guards as up and goes from the top. 5) Adversary switches network off. 6) Tor starts going through guards and fails to connect to them. 7) Adversary switches network on, and Tor establishes a circuit to the guard that it was currently walking over. If the adversary is a LAN adversary, she learns the order of the guards in Tor's list, so she can basically choose whichever guard she wants. FWIW, whether such an adversary is realistic is up for debate. - This algorithm is not very elegant. - This algorithm might make guard fingerprinting worse. Imagine that the first 2 guards in your list are actually down. Everytime Tor detects a "network up" event, it will attempt to connect to those 2 dead guards before connecting to the third guard which is up. . A LAN/WAN adversary will be able to see those failed connections and the third successful connection, which form a nice tight guard fingerprinting vector (similar to #10969). And that's all folks. I'm looking forward to some feedback on the proposed algorithms as well as improvements and suggestions. PS: I think that Tor was doing a trick with UDP to learn its public IP address or something. I need to read up on that trick, and see if it can be used to build a "network up" primitive. [0]: https://trac.torproject.org/projects/tor/ticket/12595 [1]: https://lists.torproject.org/pipermail/tor-dev/2014-June/007042.html [2]: https://trac.torproject.org/projects/tor/ticket/12450 [3]: http://stackoverflow.com/questions/3764291/checking-network-connection https://trac.torproject.org/projects/tor/ticket/12595#comment:6 [4]: https://trac.torproject.org/projects/tor/ticket/12595#comment:5

4 3

[GSoC 2014] Revamp GetTor status update #6
by Israel Leiva 15 Aug '14

15 Aug '14

Hi people. This is my sixth and last report for the 'Revamp GetTor' GSoC project. I'll try to summarize what I've done in the last two weeks. If you have any comments, please tell me! Achievements: [*] Solved pending issues on the XMPP module, and tested it on a couple more providers. [*] Created a simple guide for testing both SMTP and XMPP module. [*] Opened tickets for documenting and discussing what's been done during GSoC. [*] Forked and modified the current code* of BridgeDB Twitter distributor to create a basic Twitter module. I haven't finished this, since there are some issues** I'd like to discuss before doing further development. [*] Started to work on blacklisting of users (not finished). There are still some days left until the hard deadline for GSoC, so I'll try to finish the last point during the weekend. I haven't been able to test the SMTP module on a real environment, I'll try to do that in the weekend too. I guess I'll write another e-mail to this list once GSoC is over, to talk about the entire process and development of the project. One of the things I can tell you is that so far I've written ~1500 lines (I know, quantity doesn't mean quality). I have already communicated to my mentors that I want to keep working on GetTor after GSoC, and given that I've re-written most of the code, I'll be happy to maintain it, too. *: at least what is public on Github. **: the issues are related to Twitter API terms and privacy. I sent an e-mail to this list [0] for discussion. Feel free to comment. As always, you can view the code on [1]. Have a nice weekend! [0] https://lists.torproject.org/pipermail/tor-dev/2014-August/007320.html [1] https://github.com/ileiva/gettor/tree/master/src <https://github.com/ileiva/gettor/tree/master/src> -- israel

1 0

RPM: "hardcoded" config options in /usr/bin/torctl
by Nusenu 15 Aug '14

15 Aug '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi Ondrej, I filed a bug regarding the rpm packages [1]: "hardcoding" config options in torctl. Please let me also know what you think about migrating to systemd. thanks! [1] https://trac.torproject.org/projects/tor/ticket/12834 -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJT5kYQAAoJEDcK3SCCSvoefxoP/04Ac6/zFFg0cb8XjeNHdvjW qQAKWjKiWXRY00LWmCzeFsKp8MIyIVMDIDGja2XeaLcQd360iG/zbEKtHUm6RtXa AEH0OAzrG5eK7fUXoqXvpnSoAEkr/0cqdI1dcBJ9wUpUAMT+W6h8awpya3IuOfXv E/4V3g/C1PeQp9ISsaJIJTkn7E6enZ7teyPgW4gXx//+rljhW/mTgwGH94h2UDRE /JpH91VfBmO3zZipT1T/soIiWl8F5lm2FobOlJx5JPm9zfeeYntxVVHN7tbo6I4W xcs5Piq5O8cRvyBHliAH4i7uir/g/Fq8dwNJtRZGvyW+LLOVd98Djw+sdpqQ5Ddn zthNYU2/XUEDT1pHNYD73qrbA4fY1Thk1wU8MuYciiJvDL6uclEUFt2CBx1haAcN KJd3XiupUgY0nxpB53qUEqbX9hRmqWy8P7hbjguD5xk+exYH60VAkDBHT+HVjJS6 eWwMDiZcddPq5lNWyY1kHX0Px5xHiZWHBRUbw7OBZ/ImJAItLMIj47OTz3vD8nT/ CA5Rb5fLsJMGm1mmnqHH0wXX8ZqE60b3iBYbT/7U3fXejkqav4+PqMx3JVvN6xN6 1yb+1swrX0ZPIhKRH9CA5WGJOvrZwau9xlDj0R86U2PoV7KE7y52S9a9ywPMT/WY 2KYM9ebQa0HdPY5NeR5P =Ev1C -----END PGP SIGNATURE-----

2 7

only one signature on TBB 3.6.4
by Leif Ryge 15 Aug '14

15 Aug '14

Looking at https://www.torproject.org/dist/torbrowser/3.6.4/ I see that there is currently only one signature on sha256sums.txt for this release. As far as I can remember, every other stable release in the 3.x series has had signatures from at least 3 people. Is this an aberation or should users not be expecting multiple signatures in the future? I was just advocating for torbrowser-launcher to require multiple signatures when this happened: https://github.com/micahflee/torbrowser-launcher/issues/113#issuecomment-51… ~leif

1 0

Re: [tor-dev] [tor-talk] Tor Research Framework update
by str4d 14 Aug '14

14 Aug '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 08/14/2014 08:14 AM, George Kadianakis wrote: > Tim <t_ebay(a)icloud.com> writes: > >> On 13 Aug 2014, at 22:33 , George Kadianakis >> <desnacked(a)riseup.net> wrote: >> >>> My plan was to make a Peach fuzzer to achieve this [0], but as >>> I mentioned in a previous email I never got past the V3 link >>> handshake since I actually had to implement Tor's crypto to get >>> past. >>> >>> Someone would need to implement all this stuff to be able to >>> fuzz the Tor protocol as I was intending to. >> >> Gareth has implemented Tor's crypto in tor-research-framework[0] >> in Java. >> >> Would this be sufficient for Peach, or does it need to be written >> in Python? >> > > I don't know. I think it needs to be written in Python, or you need > to write bindings or something... But better check this yourself, > I haven't looked into Peach in years. You could also use Jython to run tor-research-framework and use the Java crypto in the Python code. See Jy2P [0] for an example, it uses Jython to start the Java I2P router and run Python code to interact with it. str4d [0] https://github.com/majestrate/jy2p > _______________________________________________ tor-dev mailing > list tor-dev(a)lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev > -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJT7HVTAAoJEIA97kkaNHPnjaQP/A+lWfVpETGUGDEVoDRnGK/X bAS0IXdt1O1G4Pv3aYSwbf/BDlJU2jkp/4OCygyIzEN8JxtJofqV9vMUlaubV31k NZJfLuojHmOICDKqWiiloYqF68BhVXF166ZXQHthCQKgZ1U8Y6QOwa0gknlB3uDn n/fZ+10fMxYoV1WjdCsBpqgsZwgVLWjt2iMmvnoILLqOENH6t4OaCCxtT1aUMDor cMnyZ9z/kaNLWqyFoFGucsMdUv9Z9WIJnLsym3wCnU2pbMTypvrDcMIZPA2U1DoW IBL5pqR7wGICjCoWEtGIvVWLHATybcMItC7I3bHsHj+06E+KDY4c3qZK07qgDTtw /3SkEt2/ZBxdbh6wcFL0oZivmQnUqTHPyOMHsDo8Id0d8qD0D2XTiBZY1w+di4ac MxaM6RH4SgK31aKq5S4Ei0ZWICFL96TO8V/dINB+UKvlgJ9Z81eSrSciaI08ol7v Z5Rx59KnRtbu7vmHpv5vxusjcM3aES1M+XGLGXRfe6G7Wf78f7GlSdsWkAi9MU0Y qMSJp94nT7npEX/dhGh0p8lBpzRsSGurLsvYn63tVI/uw4iz2ba84+cqEZl/pbcv yC1Rxzi7EOYEMNC/umxXDvsWfjPbNv0LW6rXilYT7fqPPHXi/A09N8ns5RqR63IE yoN+HGJQgR7VUYHHEKGu =biUC -----END PGP SIGNATURE-----

1 0

OFTC-i2p Relay Bot for #tor/#tor-dev
by ihave2p 14 Aug '14

14 Aug '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello and greetings, I was referred to this list by velope@oftc and have spoken directly with isis@oftc with regard to administering a relay bot for #tor/#tor-dev between Irc2p (i2p) and OFTC. To my joy, isis@oftc has happily granted permission to start a 'testing' phase of the bot pending the final decision from the Tor devs about the bot's #tor/#tor-dev fate. As it stands, the only hiccups the bot has seen were within the first 15-20 minutes of initial deployment but now, after several days, it has proven to be more helpful than not and it has since ran without incident. The bot is a barebones Limnoria with default plugins (set to private) and LinkRelay from https://github.com/ProgVal/Supybot-plugins. The bot masks hostnames with either 'oftc' or 'i2p' and currently serves no other function than relaying. As it stands, all bot responses are privmsg'd so as not to spam the channels and the bot will not relay non-privmsg relay messages i.e., joins, parts, nicks, quits, modes, etc. to anyone. I'm writing to clarify how you would like to approach the administration of the bot should things go awry. It will only connect to OFTC via tor as I cannot expose myself to clearnet/i2p identity correlation (I'm well aware of OFTC's temporary blacklistings of Tor exit nodes so I've also taken that into consideration with regard to management). Listed are my preferred options for your consideration. All comments/suggestions are welcome. 1) Off-topic chatter from i2p can be redirected to #nottor (a general "hey you, go to #nottor" to an i2p user would suffice. Note: #nottor on i2p is *NOT* relayed to OFTC but instead, redirects i2p users to our non-Tor community channels). 2) Currently, the bot will *not* auto-rejoin when kicked. If it is ever kicked, we can discuss why and then take further action if needed. 3) "ChanOp Exchange Initiative": OFTC ChanOps could have the ability to mute or kick users on i2p's side, and vice versa. This could be very useful to both parties once both have considered the other trustworthy. 4) OFTC ChanOps could have the ability to start/stop relaying and/or start/stop nick-specific relaying (tricky, but I believe possible). 5) Worst-case scenario: the bot would relay *all* OFTC users but only +voiced i2p users. Presently, I'm founder/op (the only op) for #tor/#tor-dev/#tails on Irc2p but if more ops are needed, I'll see who is available. Irc2p has flood protection and I have yet to see any Irc2p abuse outside of the occasional troll or ill-informed user. Let it be known: irc bot management/deployment is not my forte nor do I find it terribly interesting but I'm passionate about facilitating easy/anonymous communications between our two networks - so I'll "take one for the team" and try to make everyone happy with what we're achieving. For the time being, I'll attend to the bot very regularly and I don't foresee ever leaving it alone for more than a day or two (even after the 'testing' phase is complete). If I'm away for longer than that, I'll make the appropriate notifications/arrangements and, if needed, I'll simply take the relay offline. To reach me if I'm not available on either network, the bot's "real name" has my i2pmail.org (mail.i2p) address and PGP key (FYI, in case you were wondering, the bot has its own SSL cert and is registered on both networks). Thank you for your time and consideration. For those who aren't familiar with Irc2p, is not nearly as large as OFTC but I feel that strong minds/talents are on both sides and that all would benefit from the relay. I look forward to a growing bond between our communities. ihave2p 0xF8034C5F <ihave2p [at] mail.i2p> -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJT5eR2AAoJEHlp9aX4A0xf/RUQAKCAFSgiXHCI6NPwBL/+TDUp 0dp4R2oqxspcs1x7v2wV4SL2iuwYjWDMAjLtW7qwPFLLlPX+2nS0Jxbye01pLxHy ftJ0Bj+MY2q+4o4mQ5x1iGRPEukWm6zJgK0kI7BU/0yoennD4+TrBUygFIq0eS9g muJReWX3iNsFjhkJnE3ZoRA6CFequ+1Aiy5erInZkjqzG7tqlP6qZ3LM5cY4Ig3M uYWZCLBpSnlEimZX2EdPeFuwbSPGGur0QfIEfw3RHyibDy4XU1E1clAROHv+8bww x3+06CG4Xbn5UxMOicHBr//8nHFngGMWPZgKDKcPpEqiNPskkMX018xVYeLi7VYY syNC2Ioq/fY5w0XvIRZ+tQoeizndqurn2Lq5ZT+Rfwjg6irbPlOnR7Cld/SDAjZ0 7/u0pB8X//Eg/wCq+piFe7KFMGh29/QBCa6f0I8T+vQ5ktoLz8TD8Q+OVWmvk4uZ sGH7OTb6yUjwe3kGZFuHPwQ7tT/0FO4n8IEq0btAfuLU6ve2EAFl5BMie+2W8KhK zQ/SxX2ihiFaGnp7K/pVhR16n7AVLQbWFk4E5tQZgwByQSev5c+PUIdfjLBGM+lo rnU5OwEk+ppSMJeizACX9eU+j97lp8kVCAXzBjN8L5lvGTZPkbGEcL1M+KtWRI3+ ggv0IQw2pB76ulg85Dmw =m6lI -----END PGP SIGNATURE-----

3 2

Role of Bandwidth weight
by saurav dahal 14 Aug '14

14 Aug '14

Hello, I studied about section 3.5.3 computing bandwidth weights in Tor Directory Protocol Version 3. I know now how to compute the values of these weights. 1) I am not able to understand how these values are used in path selection by the client. Anybody please highlight on this. 2) There are guard flagged nodes, Exit flagged nodes and Guard+Exit flagged nodes in Tor network which are used in guard position and exit position while making circuit by the client. I know that for choosing guard flagged node in guard position, weight Wgg is used, for choosing exit flagged node in exit position, Wee is used, and for choosing Guard+Exit flagged node, Wgd or Wed is used. lets say that Wgd < Wgg and Wed < Wee. Then how is it that G+E flagged node be choosen in guard position or exit position? Thanks, -- Saurav

1 0

[Patch] src/test/test.h
by Gisle Vanem 13 Aug '14

13 Aug '14

The 'U64_PRINTF_TYPE' is defined twice for MSVC. An 'I64_PRINTF_TYPE' is needed too: --- orig/src/test/test.h 2014-05-13 23:24:22 +0000 +++ src/test/test.h 2014-05-13 23:26:51 +0000 @@ -61,7 +61,7 @@ #ifdef _MSC_VER #define U64_PRINTF_TYPE uint64_t -#define U64_PRINTF_TYPE int64_t +#define I64_PRINTF_TYPE int64_t #else #define U64_PRINTF_TYPE unsigned long long #define I64_PRINTF_TYPE long long --gv

2 1