- tor-dev - lists.torproject.org

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

Request for feedback/victims: cfc-0.0.3
by Yawning Angel 19 Apr '16

19 Apr '16

Thanks for the feedback/bug reports so far. [ PEOPLE THAT HAVE BIG SCARY ADVERSARIES IN THEIR THREAT MODEL STILL SHOULD NOT USE THIS. ] This is the third release of the archive.is based captcha-be-gone extension for Tor Browser. Relative to 0.0.2, this has a minor bugfix that fixes URLs with trendy "@" signs in odd places by replacing the URI/URL parser (Eg: "https://medium.com/@blahblahblah"). I've been busy with other things so this was the only change, but medium.com is popular enough that it deserved a new XPI. Source: https://git.schwanenlied.me/yawning/cfc XPI: https://people.torproject.org/~yawning/volatile/cfc-20160418/ Regards, -- Yawning Angel

1 0

Re: [tor-dev] Latest state of the guard algorithm proposal (prop259) (April 2016)
by Fan Jiang 18 Apr '16

18 Apr '16

Hi, the last mail got rejected by tor-dev, to keep track of this thread, sending again, sorry for disturbing, > On Fri, Apr 15, 2016 at 5:37 AM, George Kadianakis <desnacked(a)riseup.net> > wrote: > >> Fan Jiang <fanjiang(a)thoughtworks.com> writes: >> >> > [ text/plain ] >> > Thanks for the insights. >> > >> > >> >> >> It seems like the latest version of prop259 was posted a few weeks >> ago: >> >> >> >> >> https://lists.torproject.org/pipermail/tor-dev/2016-March/010625.html >> >> >> >> >> > <snip> >> >> > >> >> >> A few things: >> >> >> >> >> >> a) Are there still proposal design decisions that need to be taken >> and >> >> we >> >> >> are >> >> >> unclear on? I admit I'm a bit lost in the latest [tor-dev] >> thread, so >> >> >> maybe >> >> >> I can be of help somehow here? >> >> >> >> >> >> There are still some issues, like for_directory may leads to >> maintain >> >> two >> >> > sets of >> >> > sampled_set independently, which is not yet defined clearly in >> proposal. >> >> > >> >> >> >> Hm, how come this is happening? >> >> >> >> I would think that for_directory would now be just another filter >> (like the >> >> ipv6 one etc.) that can be applied on top of the sampled list. >> >> >> > The problem here is for_directory is a parameter of function call, that >> > means we can't do filter >> > before the call happens. Now the filter action only happens at START >> stage. >> > Maybe do a check before we return the selected guard (if not valid, then >> > continue picking new one) >> > can be a solution. >> > >> >> Hello, >> >> hm, that's an interesting problem... >> >> So we learn whether a circuit is for_directory when >> choose_random_entry_prop259() is called, but at that point the prop259 >> algorithm has already STARTed and its filtering parameters have been >> determined? >> >> So if some part of tor calls choose_random_entry_prop259() quickly twice, >> first >> with for_directory set, and the second time with for_directory unset, the >> guard >> algorithm will proceed in both cases with for_directory being set? >> Because the >> context has been set in the first call to choose_random_entry_prop259()? >> >> This seems like a problem to me, and I'm not sure how to solve it well... >> >> One way could be to use the 'cpath_build_state_t *state' in >> choose_random_entry_prop259() to be able to understand whether each call >> is >> about a different circuit or not. Then you could start a separate >> algorithm >> invocation (so new START) for each new circuit you see. >> >> But then I'm not sure how to do this without each separate algorithm call >> wrecking up the sampled_guards and used_guards lists... In the dev >> meeting in >> Valencia, we discussed with Ola and Reinaldo about using locking and >> blocking >> for this, but I'm not sure how much that would impact the performance... >> >> Do you guys have any plans here? >> >> We can have two pending_guard one for directory, one for any usage(which > will be picked by the NEXT algo, so they can be same node), > and they can be checked with directory flag before return. > Locking may not work because this algo should at least return sth before > it continues to another one, saying Dir and non-Dir are now in main loop, > Or if you have any ideas please let me know. > >> --- >> >> >> >> BTW, I also noticed that you have various global structures in prop259.c, >> like >> entry_guard_selection and used_guards and sampled_guards. I see you've >> been >> working hard on un-globalizing the entry_guards list, but I'm not sure if >> there >> is value to that if all those other structures are global. Do you have >> plans >> for making those structures local to each specific algorithm instance? >> >> I've been working on moving these other structures into a > guard_selection_t, > and hope it can help to make this algo instanceable. > > >> Cheers! >> >

1 0