tor-dev

tor-dev@lists.torproject.org

3581 discussions

PKCS#1 ASN.1 Public Key Encoding
by Gareth Owen 17 Aug '14

17 Aug '14

Hi all I wonder if someone might be able to help me with the above. I understand, that to generate the digest, the PK must be encoded in PKCS#1 format. And further to this, the public keys in the router descriptors are NOT in PKCS#1 format, but plain ASN.1. I'm trying to generate the fingerprint given just the pubilc key in Java and after almost a whole day I'm about to give up. Does anyone have a sample PKCS#1 encoded public key that is used immediately before SHA-1 to generate the fingerprint? e.g. a hex string is what I'm after. It seems there are subtle ways that an PKCS#1 can vary while encoding the same information which affects the hash, Java seems to be doing it one way, OpenSSL another, an example on stack overflow adds an extra field, etc. Many thanks Gareth

2 2

Re: [tor-dev] Decentralized VOIP over Tor
by terryz＠Safe-mail.net 17 Aug '14

17 Aug '14

I looked at Ostel. Can Ostel be routed over Tor or is there another way to get anonymity using Ostel? I said decentralized VOIP because no central servers would be managing the communications. Any Tor node could possibly be a VOIP server. The network data would have to be continually distributed throughout Tor. Also I was thinking about an option for a user to generate and use their own AES keys via air gap or Diffie–Hellman. I'm interested in this because there's way too many good people hurt by the eavesdropping on telecommunication networks. Thanks, --TZ -------- Original Message -------- From: Jordan <jordannh(a)sent.com> To: tor-dev(a)lists.torproject.org Cc: terryz(a)safe-mail.net Subject: Re: [tor-dev] Decentralized VOIP over Tor Date: Fri, 15 Aug 2014 18:43:22 -0700

2 1

On picking Introduction Points in Next Generation Hidden Services
by George Kadianakis 17 Aug '14

17 Aug '14

One missing piece of rend-spec-ng.txt [0] is a section on how HSes should pick their Introduction Points (IPs). There are three main questions here: - How many IPs should an HS have? - Which relays can be IPs? - What's the lifetime of an IP? ==Introduction Points attacks== Before exploring these questions it's a good idea to state a rough threat model for IPs. First, let's get a visual taste, here is how IPs work in the current HS protocol: https://people.torproject.org/~asn/hs/ip_placement_currently.jpg (number of IPs reduced to 2 to make it more readable) As you can see, IPs are in a good position to conduct any of the following attacks: a) IPs can count the number of introductions for a subset of clients (i.e. in the figure above, IP_1 would be able to count introductions from the clients above it). Since clients pick IPs uniformly at random, it's not hard to extrapolate from that to the total number of introductions. b) IPs have presense information about the HS. That is, they know whether the HS is up or down at a given time since they have a long-term stable circuit to it. FWIW, regular clients also have this ability by continuously "pinging" the HS and noticing when it's down. And, of course, an attacker who controls all the IPs of an HS can trivially DoS the HS (till the HS refreshes its IPs). Furthermore, as part of the Next Generation HSes initiative [0], we are considering enhancing the availability of HSes by allowing multiple nodes per Hidden Service. A plausible idea for achieving that is to allow multiple IP circuits per Introduction Point, as explained in [tor-dev] by Christopher Baines [1]. This means that IPs would work like this: https://people.torproject.org/~asn/hs/ip_placement_scaling.jpg where HS_1, HS_2 and HS_3 are the various nodes of the HS. This allows the IPs to launch the following attacks: a) IPs can learn the number of nodes of an HS, by counting the number of IP circuits on them. Also, the IPs can learn the prsense of the nodes of an HS, by looking at the state of their circuit. b) IPs can choose which HS node will receive traffic. ==How many IPs should an HS have?== Now let's investigate how many IPs an HS should have. The current situation is that HSes attempt to estimate their own popularity [2], and then they launch a number of IPs between 3 and 10 depending on how popular they think they are. FWIW, we don't really understand whether the formula works properly [3]. There are a few options for the future here: a) Fix the formula and keep number of IPs dynamic based on the popularity of the HS. This is not a bad idea. However, we should make sure that from the number of IPs you can't easily derive the number of clients of the HS. Also we should make sure that the formula works properly. b) Have a static amount of IPs per HS. For example '5' of them. I'm not sure what kind of calculations we need to do to find the right constant here (same for the (a) option). c) Have a static amount of IPs per HS, but also allow this to be configurable by the HS operator. The idea here is that popular HSes can pump up the number of IPs to make the service more reachable. It's worth noting that HSes who do so will stand out as manually configured; not sure if any other partition attacks can happen here. Also, there is also the danger of all HS operators thinking they are special and pumping the number of IPs to 42. Generally, we want to have a healthy amount of IPs (so that they don't get DoSed, and that requests get load balanced nicely), but also not too many because every HS having many IP circuits will put a load to the network (especially with services like Torchat where each client is an HS), and also because we want to avoid too many nodes becoming our IPs over time (more on this below). ==Which relays can be IPs?== This seems to be the easiest question here and Tor is currently handling it well by only restricting IPs to be Stable nodes [4]. This means that with the current network, we have about 4000 possible IPs to choose from [5]. This makes sense since we want to maximize the set of possible IPs, but we also want them to be stable to decrease their natural churn. ==What's the lifetime of an IP?== Another hard question: How long should we keep IPs for? Currently, Tor keeps IPs for a random time between 18 to 24 hours [6]. This seems like too short of a period if we actually want to protect against adversarial nodes ever becoming our IPs: Consider an HS with 5 IPs that rotates them every 24 hours, in only two months it will use 300 nodes as IPs plus the natural churn (which is not negligible at all). With that in mind we need to look at all the possible attacks that IPs could launch and decide whether they should be short-lived or long-lived. For example, waldo in a related thread [7] [8] asks for short-lived IPs, but recent entry guard research has shown that making guards more long-lived is actually beneficial for security [9]. I'm personally leaning towards more long-lived IPs but I still don't know what our constants should be. I could see anything from a week, to a month, to 5 months as reasonable IP lifetimes. We also need to look at INTRO_POINT_LIFETIME_INTRODUCTIONS, since apparently in the current code, IPs will expire on their own if they perform more than 16384 introductions. ==Conclusion== I hope that this thread serves as a good start on discussing Introduction Point security. After we take some decisions, we will need to write them down as a proposal and incorporate them in rend-spec-ng.txt. Also, this thread does not explore other IP matters, like how many HS nodes should correspond to each IP if we go ahead with the scaling ideas [10]. I decided to not include this in the discussion, so that we keep it simple and also so that we don't focus on a particular scaling scheme. References: [0]: https://gitweb.torproject.org/torspec.git/blob/HEAD:/proposals/224-rend-spe… [1]: https://lists.torproject.org/pipermail/tor-dev/2014-April/006788.html [2]: https://gitweb.torproject.org/tor.git/blob/ab3d5c049032651a9c9164262f9a8f81… [3]: https://trac.torproject.org/projects/tor/ticket/8950 [4]: https://gitweb.torproject.org/tor.git/blob/bb68c731b897a967a4b7eb138728fa07… [5]: https://metrics.torproject.org/network.html#relayflags [6]: https://gitweb.torproject.org/tor.git/blob/bb68c731b897a967a4b7eb138728fa07… https://gitweb.torproject.org/tor.git/blob/bb68c731b897a967a4b7eb138728fa07… [7]: https://lists.torproject.org/pipermail/tor-dev/2014-May/006815.html [8]: waldo also mentions an IP guard discovery attack in another reply of his: https://lists.torproject.org/pipermail/tor-dev/2014-May/006843.html However, I'm not sure if it's actually doable, since I think that HSes will discard an IP that has failed a circuit. We need to look into this more seriously. [9]: https://blog.torproject.org/blog/improving-tors-anonymity-changing-guard-pa… [10]:https://lists.torproject.org/pipermail/tor-dev/2013-October/005615.html https://lists.torproject.org/pipermail/tor-dev/2013-October/005683.html

3 3

Orbot & Orfox - GSoC bi-weekly report 6
by Amogh Pradeep 17 Aug '14

17 Aug '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Status Report 6 August 17th, 2014. So the past couple of weeks have been a little more hectic than usual, but these are the things that I got to work on: 1) Continuing work on fixing leak: On the Mozilla side, I had a long discussion with snorp and rnewman, they seem to have an idea to solve proxying everything through the added proxy settings but this is going to be one massive bug, so I haven't been able to land it yet. Bugs are http://bugzil.la/942652, http://bugzil.la/942653 and http://bugzil.la/942654. Fixing the first two should solve the dns leak. 2) Temporary loadFavicon fix: As you will be able to see my changes at https://github.com/amoghbl1/gecko-dev/commit/4baa2111b7d8a90af5b7bb787cc9d5… , I have a temporary fix for this, but hopefully this won't be necessary after the above mentioned bugs are fixed. 3) Getting Orfox built on the guardian projects build server: Hopefully this will be done before Monday, although all the code for the app is there, if we could provide the apk officially before hard pencils down, it would be nicer. This has been one great summer for me, I've had loads of fun, learned a lot and met some amazing people. I thank everyone for their support and look forward to continuing working with you guys. -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJT8KzvAAoJELm/SSKdtjUkrS8IAIrgJYhvdoa6+7HGfHPqu0cq ocQX8Hd67hXwHrtGHmmdS3c7aCOyV4K0g/aGi4WTVbFRqd+tFzHNK9zTKYpUvXXP wfuORN/SKWCnjLrmjQ6ZXks1+mq7lnaTxSAPYo4GCJj6nTbDzDZryHlHncxMQheA VoU+0JV9bg7OAYpLDaF/4/TPSqG1KE5H5Ae633dXBt0/dmMhFmhNtfJdbNrlilIz UleRhERZe5h94Bz6QYJtCeD0zOdnHxI0udT73c7MYCLTiS7SxFssZYuUiE1grpHl GgVvnR8vfwFCgz7O6WLven+bfOMGZV0ZJZCIPopyZ7HXw034WmTgKLbLQl2H1cM= =ymdp -----END PGP SIGNATURE-----

2 1

GSoC final progress update (Stegotorus)
by Noah Rahman 17 Aug '14

17 Aug '14

The following tickets were largely achieved (last is in process of debugging) - adding config file (see branch https://github.com/TheTorProject/stegotorus/tree/f--modus-operandi) - adding elligator handshake ( https://github.com/TheTorProject/stegotorus/tree/f--circuit-handshake) [0] - moving remaining stegs over to class-based structure (see note (1) below) (https://github.com/TheTorProject/stegotorus/tree/f--file-stegize-swf-js-pdf ) The following are "on deck" and I intend to work on them after GSoC code submission date of August 22. - SOCKS proxy over wire from Tor (see https://github.com/SRI-CSL/stegotorus/commit/2d4ac59b8112611a7b63a1c5b15dfb… and https://github.com/SRI-CSL/stegotorus/commit/c799f30249c5e1dfbcc1adfe68f6bd… ) - adding SRI code into Tor fork (such as new JSON steg) - this was simply not anywhere near ready in time for the summer, but now has TBB and gitian ready to go - making transparent proxy robust (as security measure in case stegotorus server is probed) [0] this needs one last check for out of order packets. [1] I was hypothesizing that new larger default buffer size or excessive pointer casting was causing performance issues, but perusal of JavaScript patch via valgrind revealed memory leaks in the decompression methods of several steg mod classes. I am in the process of addressing this. This causes intermittent, not consistent failures, so unit tests would not consistently catch this.

1 0

Re: [tor-dev] Decentralized VOIP (or video chat) over Tor
by terryz＠Safe-mail.net 16 Aug '14

16 Aug '14

FreeNote's overview is almost the same as what I'm thinking. I've used GTK and GStreamer for Video in the past and implemented mobile and desktop IPTV applications using Qt, SDL, Ogg, Theora, and Vorbis. This VOIP over Tor idea came to mind after developing a prototype VOIP application using Qt with custom protocols and encryption. The users generated their own AES keys and added them to the VOIP client through the user-interface. The VOIP server didn't do any encryption/decryption only the client and only public-key information was allowed to be transmitted to peers, but the packets did go through central servers. It wasn't decentralized and no anonymity was in the design. It would be nice to have this work over Tor. I would like to focus on this task if possible. --TZ -------- Original Message -------- From: Griffin Boyce <griffin(a)cryptolab.net> Apparently from: tor-dev-bounces(a)lists.torproject.org To: tor-dev(a)lists.torproject.org Subject: Re: [tor-dev] Decentralized VOIP (or video chat) over Tor Date: Fri, 15 Aug 2014 22:14:09 -0400 > > This is similar, though not *quite* the same. A while back ioerror > released FreeNote[1], which makes it easier to broadcast audio and video > on a hidden service. This is a pretty cool idea and works pretty well. > AND it should be pointed out that two one-way conversations can be a > two-way conversation by virtue of just sharing the links over OTR [2]. > > Scott Ainslie and I discussed the possibility of taking that basic > two-way conversation hidden service concept and making a GUI for it with > Glade+GTK. Unfortunately, neither of us really have the time or > expertise for this endeavor. I got as far as wireframing some ideas > before going face-first into developing a more time-sensitive project > [3]. I'd love it if someone actually did this and released their > prototype as free software. There are way too many issues with > centralized services like Skype and Google Hangouts.[4] > > best, > Griffin > > > [1] https://github.com/ioerror/freenote > [2] Of course, if someone shares the links further, there can be privacy > issues. > [3] Satori: https://github.com/glamrock/Satori > [4] and jitsi never recognizes my fucking microphones =/ > > On 2014-08-15 21:43, Jordan wrote: > > Hi, terryz, > > > > Thanks for the idea! Today I was actually wondering if *video* were > > possible, > > too. :-D > > > > Guardian project has [Ostel](https://guardianproject.info/apps/ostel/). > > Is > > that what you're wanting? If not, was there a feature you were wanting > > from > > Ostel or another application that has features that Ostel doesn't? > > > > As for "decentralized," I think the whole point of tor is that tor > > itself is > > decentralized. Check out [Running a relay] > > (https://www.torproject.org/docs/tor-doc-relay.html.en) to see how this > > works. > > > > Again, thanks for the input! :-D > > > > On Friday, August 15, 2014 05:53:44 PM terryz(a)Safe-mail.net wrote: > >> 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 > >> _______________________________________________ > >> tor-dev mailing list > >> tor-dev(a)lists.torproject.org > >> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev > > > > _______________________________________________ > > tor-dev mailing list > > tor-dev(a)lists.torproject.org > > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev > _______________________________________________ > tor-dev mailing list > tor-dev(a)lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

1 0

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

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

tor-dev