April 2016 - tor-dev - lists.torproject.org

Tor Browser Bundle on musl libc systems
by Daniel Simon 25 Apr '16

25 Apr '16

Hi, the Tor Browser Bundle binaries available at https://dist.torproject.org/torbrowser/5.5.4/ do not run on musl-libc-based systems, like Void Linux, Alpine Linux, and other Linux distributions. I believe that's the case because the Tor Browser Bundle binaries are compiled dynamically to glibc, making them fail when ran on systems that any other libc. I'm sending this message to the Tor mailing list and to the Musl mailing list, so we can together find a solution. I think there are 4 possible solutions: - the tor developers can provide binaries built with musl libc - the tor developers can provided statically compiled binaries (with any libc, but musl is especially good for this). These statically compiled binaries would run on any system independently of the libc. - the musl libc developers could identify why the binaries fail on musl and try to add compatibility - Linux distributions that use musl libc could figure out how to compile the Tor Browser Bundle from source and provide binaries themselves What does everyone think about these possible solutions? Which one is the best? Are there any others you can think about? Thanks for everyone's time, D. Simon

1 0

meek-server performance improvements?
by David Fifield 25 Apr '16

25 Apr '16

I saw you say on IRC that you had an idea for improving the efficiency of meek-server. What's your idea? The server hosting meek-azure is passing 90% CPU at times. One idea I've seen is using one connection for upstream data (data-carrying POSTs, emptry responses), and one connection for downstream data (GET, one big chunked download). As I understand it, this is what Lantern's enproxy does: https://github.com/getlantern/enproxy So far I've avoided this idea because of the possibly weird traffic patterns. I've also done some preliminary work on allowing the server to send data in larger chunks, which should reduce polling: https://trac.torproject.org/projects/tor/ticket/12857#comment:4 All that's really needed here is a decision on how to let the client indicate that it supports such a server, as the change is backward incompatible.

2 2

Onioncat and Prop224 (was Re: [tor-onions] Hidden datagram service)
by Tim Wilson-Brown - teor 25 Apr '16

25 Apr '16

> On 22 Apr 2016, at 17:03, grarpamp <grarpamp(a)gmail.com> wrote: > ... > > https://www.onioncat.org/ > https://www.cypherpunk.at/onioncat_trac/ > > FYI: The onioncat folks are interested in collaborating > with tor folks regarding prop224. > > https://gitweb.torproject.org/torspec.git/tree/proposals/224-rend-spec-ng.t… Hi grarpamp, I'm interested in what kind of collaboration onioncat would like to do on prop224, next-generation hidden services. It would be great to work this out in the next few weeks, as we're coding parts of the proposal right now. But the tor-onions mailing list is to discuss the technical details running onion services. Can we discuss onioncat, tor, and the development of prop224 on tor-dev mailing list? Tim Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP 968F094B ricochet:ekmygaiu4rzgsk6n

1 0

[GSoC16] A website to improve Tor fingerprinting defenses
by Pierre Laperdrix 24 Apr '16

24 Apr '16

Hi Tor Community! My name is Pierre and I'm a second year PhD student from France working on browser fingerprinting. I'm really fortunate that my proposal for this year Google Summer of Code has been been selected. My goal for this summer is to set up a website similar to Panopticlick or AmIUnique that will collect data to improve Tor fingerprinting defenses. The collected data will be used to detect if there are differences between browsers that could ultimately lead to a user's identification. With that knowledge, developers will be able to patch the Tor browser to prevent leak of identifiable information and reinforce the anonymity of Tor users. I also plan to add details on browser fingerprinting for users who are not familiar with the subject so that they may learn about its mechanisms and the potential dangers linked to it. I'll also try to implement a page where Tor users can see how far they are from an "acceptable" fingerprint so that they may tweak their browser in order to have a fingerprint that is shared by many more users. I'll officially start coding at the end of May but in the mean time, I'll familiarize myself with the Django framework that I plan to use and I'll lock down the exact set of features that I'll include in the very first version of the project. My primary mentor is Georg and my secondary mentors are Gunes and Nicolas. I'll post bi-weekly reports to the tor-dev mailing list and to my blog to inform everyone of my progress. If you have any questions about the project, don't hesitate to ask me. The name of the project has not been found yet so feel free to send me any suggestions that you may have. You can reach me here or on IRC where my handle is SuperOctopus. Cheers! Pierre

3 5

CollecTor has a new Git home
by Karsten Loesing 24 Apr '16

24 Apr '16

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi devs, the CollecTor Git repository just moved from metrics-db to collector: https://gitweb.torproject.org/collector.git/ The old name made sense when the Tor network data archive was still part of Metrics, but it's rather confusing since CollecTor and Metrics are two distinct services. Therefore the renaming. If you have cloned the CollecTor sources in the past, you'll want to update the Git remote. The following line worked for me, but there are probably a dozen other ways: git remote set-url origin https://git.torproject.org/collector Let us know if you have any trouble. All the best, Karsten -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJXHIcDAAoJEC3ESO/4X7XBD0MH/jz5sq9KAieUKPxvg3sW0v5t iEbDI5wFav/KGJpa7TaBZ8+XJ3KNm8N97fVsQwryGsXVIugci0eH72x+WedM4TAZ +JyRaAmaRroz+etPByQFU17SHisJX4wA2yJ9KwO1XmxhWKpiIMKV4pMFkCqOjDER VMmu6AGXRihoUrkPpsXn0iXHK7s1gLyfBeAkC5lWO8GM2FedVP2xkzSXKaM15+Y9 oP8UZ0gFaIWIhIok0i/GdClJHIQxppBW+aqJ4g5wFx3J8rHczvGEpTMF9oy+xK2D LaZTmqWHWMvdjVaF968KdFkW2GMhiGf+znYuZS1LpChu7WAeGANEanR5yaoE9J0= =X47s -----END PGP SIGNATURE-----

1 0

[GSoC] CONIKS for Tor Messenger - gsoc.hello()
by Huy Vu Quoc 23 Apr '16

23 Apr '16

Hi everyone! I'm Huy, a senior year undergraduate from HUST-Vietnam, who is starting to work with CONIKS for Tor Messenger as a part of Google Summer of Code. This project aims at implementing a CONIKS server for key verification and a CONIKS client which integrates with the Tor Messenger client. The details of CONIKS system is described in [0]. My mentors are Marcela and Arlo. I will start with this project soon, may be on the first day of May and finish at the end of July. Currently, I am studying deeper about crypto primitives. After that, I think I will speed up with code base in the GitHub :) I will be on IRC as c633, in GitHub as c633. I will send bi-weekly status reports to this list, and also share it on my blog [1]. Cheers! Vu Huy — [0]: https://www.usenix.org/system/files/conference/usenixsecurity15/sec15-paper… [1]: http://c633.net

1 0

[GSoC '16] Exitmap Improvements Project - Hello Tor!
by Mridul Malpotra 23 Apr '16

23 Apr '16

Hi everyone! Introduction: ----------------- I'm Mridul, a senior year undergraduate from IIIT-Delhi. I am really thrilled to have been selected in GSoC 2016 for the Exitmap improvements project! It's an amazing opportunity and I hope to contribute something substantial to the Tor community. My IRC handle is mtyamantau. Details: ------------ My primary and secondary mentor will be Dr. Philipp Winter (phw) and Damian Johnson (atagar) respectively. I'll be primarily active on #tor-dev on irc.oftc.net and on tor-dev(a)lists.torproject.org. About project: ------------------- The project is mainly focused around Exitmap improvements, with the three major aspects being implementing autonomous scanning, multiple user interaction in Tor Browser and a system for implementing automated data collection from multiple users[1]. My full proposal is linked below[2] for more information on this. I Project details: -------------------- Official start and end dates: 23rd May (Mon) to 29th August (Mon). For now, I plan to start reading and getting myself familiarized with the codebase before that. Also, I have still some uncertainty and questions in certain sub-tasks, which I hope to resolve with the Tor community. I will be sending bi-weekly project reports to tor-dev(a)lists.torproject.org. They will mainly be on the progress that I have made that highlight the work done in that duration. Cheers! Mridul (mtyamantau) [1] https://summerofcode.withgoogle.com/projects/?sp-page_size=48#6137867067719… [2] https://docs.google.com/document/d/1AqjH3AsBbfesJg36SZg1frPQsdpAnJmzH8k1-G6…

1 0

Questions about "Tor Messenger CONIKS integration"
by Go 21 Apr '16

21 Apr '16

Hi, CONIKS seems to be a very useful system. Just curious: do Tor messenger users need to hand out their real identities (facebook account, twitter account, etc.) to CONIKS servers? If so it seems dangerous to put all the identities in a centralized service. If the CONIKS servers have been compromised, will the attacker be able to figure out the social networking profiles of Tor messenger users? Thanks!

4 6

prop224: HSDir caches question with OOM
by David Goulet 21 Apr '16

21 Apr '16

Hi! (For the following, I'm only talking about HS directory.) Here is my conundrum. I was working on plugging the new cache for proposal 224 into our OOM. I stumbled upon a fun problem. We plan to have both current and new HS protocol in parallel. This means two caches for both version 2 (current) and 3 (prop224). So far so good. However, here is the problem. Now, our OOM handlers is called in: cell_queues_check_size(). The heuristic is basically: /* If we're spending over 20% of the memory limit on hidden service * descriptors, free them until we're down to 10%. */ Considering we have _two_ caches now, we somehow have to cleanup both of them "evenly" that is if we have to remove 20kb we either remove 10kb on each (if possible) or we actually clean them by entry expiry time instead regardless of which version. I think the latter is what we want but then it complicates things a bit since both cache contains _different_ data struct. and indexed with different keys (DIGEST vs DIGEST256). One option here is to go over all entries in both cache, create temporary objects and put them in a sorted list (by expiry time). Those "temp object" would contain something like: 1) cache version, 2) expiry time and 3) index key. Once done, we go over that list and delete entries until we reach our number of bytes we need to remove. This could work since we would do that when we are at 20% memory but still it requires allocating some small objects to _clear_ our memory... Someone has maybe something _better_ to propose? :) (keep in mind that minimal change to the current HS code is preferable. I know that unifying both caches somehow would help but that's lots more work! and the new cache for prop224 will be able to support versionning for which our current one doesn't, it's baked for v2.) I'm asking because this will require some refactoring for which I want to make sure we are in agreement on how to proceed and it doesn't end up not the right solution. Basically my goal is to move the OOM handler for both v2 and v3 to one single function called hs_cache_handle_oom() and from which we'll do the gymnastic describe above. We'll stop calling rend_cache_clean_v2_descs_as_dir() explicitely after that in cell_queues_check_size(). Cheers! David

5 8

Comments on proposal 224 updates
by Nick Mathewson 19 Apr '16

19 Apr '16

I'm behind on this! But let me comment on the stuff that got merged recently. "prop224: Remove the MAINT_INTRO feature." "prop224: Clarify backwards compatibility sections slightly." "prop224: Clarify use of shared random values." "prop224: Fix undefined variables in the ntor section." Looks ok. "prop224: Add missing key expansion section for rendezvous crypto." KDF-Tor is a legacy algorithm, and we want to get away from SHA1. We don't use KDF-Tor with NTOR. Let's kill it for new use. I'd suggest HKDF-SHA256 or SHAKE, both of which we have implemented already. "prop224: In cells, replace TYPE/LEN/KEY with just TYPE/KEY." I'm not sure about this change. If we ever add a third key type, all of the cells will be unparseable. "prop224: Various improvements." There's no point in using HKDF with SHAKE; we should just use SHAKE as the KDF.

2 2