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

GSoC: Questions on allowing for more DNS request types
by Lucille Newman 03 Apr '17

03 Apr '17

Hello, I was interested in the project for allowing any kind of DNS support in Tor for GSoC, or, since it is late for that deadline, then also otherwise. After reading proposal 219, I have some questions. 1. A comment by NM suggests that we should specify exact behavior when generating DNS packets (line 56). Should the DNS packets not be generated as according to RFC 1035? Are there other things that need to be taken into consideration here? 2. Another comment (line 63) asks whether 496 bytes is enough for the DNS packet of a DNS_BEGIN cell. Since QNAME can be arbitrarily long, I suppose it is possible that 496 is not enough? If this seems like a reasonable concern, then maybe we could do a similar thing to the DNS_RESPONSE cells with allowing multiple cells for a single question and having a flag to indicate the last cell? 3. What would cause a DNS_BEGIN request or response to be aborted (line 105)? 4. How do we differentiate special names like .onion, .exit, .noconnect (line 145)? 5. The comments at (lines 135-143) indicate that it might not be necessary or practical to refuse requests that resolve to local addresses. This means that such queries will not be sent, but an error will be returned before sending to a DNS server? Thanks so much. Best, Lucy

2 1

Tor in a safer language: Network team update from Amsterdam
by Sebastian Hahn 03 Apr '17

03 Apr '17

Hi there tor-dev, as an update to those who didn't have the chance to meet with us in Amsterdam or those who haven't followed the efforts to rely on C less, here's what happened at the "let's not fight about Go versus Rust, but talk about how to migrate Tor to a safer language" session and what happened after. Notes from session: We didn't fight about Rust or Go or modern C++. Instead, we focused on identifying goals for migrating Tor to a memory-safe language, and how to get there. With that frame of reference, Rust emerged as a extremely strong candidate for the incremental improvement style that we considered necessary. We were strongly advised to not use cgo, by people who have used it extensively. As there are clearly a lot of unknowns with this endeavor, and a lot that we will learn/come up against along the way, we feel that Rust is a compelling option to start with, with the caveat that we will first experiment, learn from the experience, and then build on what we learn. You can also check out the session notes on the wiki (submitted, but not posted yet).[1] The real fun part started after the session. We got together to actually make a plan for an experiment and to give Rust a serious chance. We quickly got a few trivial things working like statically linking Rust into Tor, integrating with the build system to call out to cargo for the Rust build, and using Tor's allocator from Rust. We're planning to write up a blog post summarizing our experiences so far while hopefully poking the Rust developers to prioritize the missing features so we can stop using nightly Rust soon (~months, instead of years). We want to have a patch merged into tor soon so you can all play with your dev setup to help identify any challenges. We want to stress that this is an optional experiment for now, we would love feedback but nobody is paid to work on this and nobody is expected to spend more time than they have sitting around. We have committed to reviewing any patch that includes any Rust code to provide feedback, get experience to develop a style, and actually make use of this experiment. This means we're not ready to take on big patches that add lots of tricky stuff quite now, we want to take it slow and learn from this. We would like to do a session at the next dev meeting to give updates on this effort, but in the meantime, if team members would like to start learning Rust and helping us identify/implement small and well-isolated areas to begin migration, or new pieces of functionality that we can build immediately in Rust, that would be really great. So, for a TLDR: What has already been done: - Rust in Tor build - Putting together environment setup instructions and a (very small) initial draft for coding standards - Initial work to identify good candidates for migration (not tightly interdependent) What we think are next steps: - Define conventions for the API boundary between Rust and C - Add a non-trivial Rust API and deploy with a flag to optionally use (to test support with a safe fallback) - Learn from similar projects - Add automated tooling for Rust, such as linting and testing Cheers Alex, Chelsea, Sebastian [1]: Will be visible here https://trac.torproject.org/projects/tor/wiki/org/meetings/2017Amsterdam/No…

4 3

Re: [tor-dev] GSoC 2017 - Feedback Extension for Tor Browser
by Jayati Dev 03 Apr '17

03 Apr '17

Dear Mentor, Please find my draft application here: https://docs.google.com/document/d/1AItxT3k-K1tSHa0OJDl3AC4BL_xYoCUWv6IHDnb…. I have also uploaded it through the GSoC 2017 Official Website. Thank you for your time and effort, Sincerely, Jayati Dev

2 1

Mailing List Etiquette Reminder
by grarpamp 02 Apr '17

02 Apr '17

New members are very welcome and valued whether through gradual accretion or project influx such as GSOC's. In order to ensure messaging efficiency and clarity... - Reply *below* what others have written. Do not "top post". - Trim out and *delete* irrelavant portions of what others have written, so to clearly include only that part of which you are replying to. Do not "bulk quote" chains of replies. - *Interleave* your replies within the physical lines others have written so that what specific part you are replying to is clear. "Reply in context." - Use "text/plain UTF-8" encoding, disable all "HTML" when sending. - Wrap message lines at roughly 68-72 characters long. - Be aware of how changing subject line, and reply-to and references headers can break threading, and use it carefully. For more info you can search "mailing list etiquette" on any search engine. Thanks.

1 0

GSoC 2017 - unMessage: a privacy enhanced instant messenger
by Felipe Dau 02 Apr '17

02 Apr '17

Hello, I am a Computer Engineering student at the Federal Technological University of Parana in Brazil and I would like to present you a peer-to-peer privacy enhanced instant messenger called unMessage [0]. I have been working on it for a while with David Andersen [1] (my advisor) and we have recently released an alpha version which should be easy for developers to install and test. It uses the Double Ratchet Algorithm [2] for encryption, Onion Services for transport metadata minimization, its own protocol for application metadata minimization, and as a result, provides private and anonymous conversations. It currently has basic features such as message exchange, user authentication and we very recently enabled voice chat using the Opus codec [3] for constant bitrate encoding. unMessage is a Python application that mainly uses pyaxo's [4] implementation of Double Ratchet Algorithm and txtorcon's [5] implementation of the Tor Control Protocol. Since its current (alpha) release, we have been discussing it with Patrick Schleizer [6] and HulaHoop [7] from Whonix [8], who are making great contributions to help us test it, as well as suggesting new features and improvements. We are also working to run it on Whonix (which will also allow it to be run on Tails) with help from meejah [9] by adding a new feature to txtorcon to make unMessage (and all the apps that use txtorcon) "Control Port Filter friendly". As we believe unMessage has potential to become a great privacy enhancing app with a code that is simple, readable and therefore easy to maintain, Patrick suggested that I submitted a proposal to have unMessage as one of the GSoC projects. We expect to implement fixes, improvements and features from our discussions in order to turn it into a maintainable, feature-rich and useful app which the community can benefit from. There are currently some "developer centered" tasks I can work on such as: - Create a test suite (with pytest) - Make unMessage's own functions/methods behave like a Twisted API should - Use automat for its finite-state machines - Make use of a logging tool - Improve comments/document the code As well as some "user centered" tasks: - Whonix/Tails support - Improve the GUI and CLI - File transfer - Use a friendlier approach for users to handle keys instead of the current base32/64 encodings - Connect/launch Tor automatically depending on what is available - Offline messages (All the other ones can be found in the issue tracker [10]) My intention with this post is not only to present unMessage to tor-dev but also see if someone is interested in mentoring me as it is not one of the official ideas but hopefully sounds like a good project. If someone gets interested, please let me know so that we can discuss which tasks would be interesting for this project and I am able to write a proposal. Thanks! -Felipe [0]: https://github.com/AnemoneLabs/unmessage [1]: https://github.com/rxcomm [2]: https://whispersystems.org/docs/specifications/doubleratchet [3]: https://opus-codec.org [4]: https://github.com/anemonelabs/pyaxo [5]: https://github.com/meejah/txtorcon [6]: https://github.com/adrelanos [7]: https://github.com/HulaHoopWhonix [8]: https://whonix.org [9]: https://github.com/meejah [10]: https://github.com/AnemoneLabs/unmessage/issues

4 13

Re: [tor-dev] Anonymous Local Count Statistics Using PCSA - GSoC
by Jaskaran Singh 02 Apr '17

02 Apr '17

Oops, clicked the SEND button accidentally. Sorry! You can ignore it. > Ah! That reminds me that OP(of this thread) should also aim to fix #8786 > along with that could enable such a counting technique for Pluggable > transports. > > Now coming to the main point, > >> In addition, each user doesn’t necessarily correspond to >> a different IP because of NAT, and so counting connections may actually be >> more accurate. > I agree, -- Jaskaran Veer Singh (jvsg) jvsg1303 at gmail dot com PGP 2814 3FB7 A32D 429B 092E 27F0 8AA3 C532 9E1A 6AD8

1 0

Anonymous Local Count Statistics Using PCSA - GSoC
by samir menon 02 Apr '17

02 Apr '17

Hi there! I'm Samir, a Computer Science student at Stanford University, with a focus in applied cryptography and computer security. This summer, I want to work (through GSoC) on computing usage statistics without keeping IP addresses in memory (see tickets #7532 and #15469) [1] [2]. Currently, we keep sets of IP's (or hashed IP's) in memory so that we can compute the number of unique client connections. This has been pointed out as a pretty serious concern, because the IP's themselves are sensitive info that we don't want an attacker to acquire, but the statistics are relatively valuable. As Nick first pointed out in #15469, we can use proven techniques to compute these statistics without actually explicitly storing any IP's (or IP hashes) in memory. The technique I want to use, "Probabilistic Counting with Stochastic Averaging", or PCSA, is relatively well-studied, and can provide good estimates (<5% error) of the number of unique elements in a time series. The basic idea is to count the number of 0's before the least significant 1 in every (Jenkins hashed) IP, and then recognize that the more unique IP's we encounter, the more likely it is that we see a hashed IP with a large number of 0's before the least significant 1. (Shoutout to Jaskaran and [3] for helping me understand this). A more detailed explanation and more resources for understanding PCSA are in the proposal. Here is my draft proposal (also attached, but links don't work): http://stanford.edu/~samir2/TorGSoCApplication.html I'd love to hear feedback on it - what's feasible, what's most useful, and what I should focus on, etc. You can also chat with me about it on IRC at `samir2`! Thanks, ~Samir Menon menon.samir(a)gmail.com Stanford University, B.S. Computer Science, 2019 [1] https://trac.torproject.org/projects/tor/ticket/7532 [2] https://trac.torproject.org/projects/tor/ticket/15469 [3] https://www.cs.princeton.edu/~rs/talks/AC11-Cardinality.pdf

6 9

GSoC 2017 - Feedback Extension for Tor Browser
by Jayati Dev 02 Apr '17

02 Apr '17

Dear Mentors, I am a final year student in Electronics and Communication Engineering, and I wanted to work on the 'Feedback Extension for Tor Browser' project as a part of GSoC 2017. I have been working on the design and implementation of the extension here https://github.com/devjayati/TestExtension (which also serves as a qualifcation task). I have also made a draft proposal and submitted it for review. If there isn't anyone already assigned to the project, it would be wonderful if you could please consider my proposal and also comment on the draft. Sincerely, Jayati Dev

2 1

Proposal xyz : Count Unique IP addresses in an anonymous way
by Jaskaran Singh 02 Apr '17

02 Apr '17

Hi, Please have a look at this proposal. Will replace xyz with more meaningful numbers once this is finalized. Comments, suggestions and criticism are welcome. ------------- Filename: xxx-Count-unique-IPs-in-anonymous-way.txt Title: Count Unique IP addresses in an anonymous way Author: Jaskaran Veer Singh Created: 14 March 2017 Status: Draft §0. Introduction Currently, guard relays and bridges maintains a list of IP addresses of the devices that connect to it for various reasons such as for use by the bridge to check which country has them blocked. This is dangerous because if any of these tor instances get compromised, clients will be de-anonymized. To solve this issue, a new data structure that keeps a track of unique IP addresses seen but does not directly keep a list of them is proposed in this document. §1. Specification §1.1. Notation Let `a^b` denote the exponentiation of a to the bth power. Let `a == b` denote the equality of a with b, and vice versa. Let `a := b` be the assignment of the value of b to the variable a. Let `a / b` denote the division of a by b. Let `a <= b` denote that a is less than equal to b. Let `a >= b` denote that a is greater than equal to b. §2. Research There are three ways to solve this problem. All the three ways are actually Big Data Algorithms. A few problems arises for each of these algorithms since they are made for big data but the data we would provide is not necessarily big. §2.1. Bloom Filter[1] A bloom filter maps the input to positions on the bitmap after passing through 2 or more hash functions. Later any new input are mapped onto this bitmap in the same way to check whether this value is already present in the set. The feature of this bitmap is that collisions could happen. And this collision creates deniability. When collisions happen, On the one hand, one of the input doesn’t count to be unique (although in reality, it is), and on the other hand, this is beneficial since this creates deniability. The person who gets hand on this data structure could never be 100% sure about the original inputs. So we get the job done successfully at some error rate. §3.1.1. Obstacle Suppose if the number of inputs is small. Let’s say we receive just 1 connection in a day from some small, less busy country like Estonia. In that case, there might not be any chance for collision and the adversary could determine the IP address with some brute force. Hence this algorithm isn’t suited for us. §3.2. Rappor[2] Randomized Aggregatable Privacy Preserving Ordinal Responses is an algorithm where the system adds some deterministic and nondeterministic noise to the data that has to be stored. This creates deniability. In our case, we don’t need to have deterministic noise added at first stage. So we’ll just stick to adding non deterministic noise and storing it in a bloom filter. One thing to note here is that, we should not accept output of the non deterministic randomizer which can be traced back to any IP address of Group D or Group E since those IP addresses are not in use and the adversary could easily know that those have been produced after adding random noise. §3.2.1. Obstacle Using brute force technique, the adversary could check to see whether the IP address stored is the correct one or produced using random noise. In this technique, the adversary could compare those IP address (obtained via brute force) to the directory of what IP addresses are allotted to what country. The one that does not match, is the one that has been faked by using random noise. §3.3. Probabilistic Counting with Stochastic Averaging[3] (PCSA) It is based on FM sketches. The algorithm goes as follows: | m = 2^b # with b in [4...16] | bitmaps = [[0]*32]*m # initialize m 32bit wide bitmaps to 0s | | # Construct the PCSA bitmaps | for h in hashed(data): | bitmap_index = 1 + get_bitmap_index( h,b ) # binary address of rightmost b bits | run_length = run_of_zeros( h,b ) # length of the run of zeros starting at bit b+1 | bitmaps[bitmap_index][run_length] = 1 # set the bitmap bit based on the run length observed | | # Determine the cardinality | phi = 0.77351 | DV = m / phi * 2 ^ (sum( least_sig_bit( bitmap ) ) / m) # the DV estimate So, Error is bounded by 0.78/sqrt(m) §3.3.1. Obstacle This algorithms stated above is made for use on large databases. Infact, these were invented to save time and space while doing basic set operations on data with high cardinality. But the data we would provide as an input is not necessarily of high cardinality. Since we would be counting numbers for each country separately, so the expected value of the input cardinality would be : 0 <= C <= 2500 where C is the actual cardinality of the input data. §3.3.2. Workaround As a workaround, we could introduce a correction term for small values of cardinality. So our final formula could look something like: DV(S1,...,Sm) := m· (2^(Z/m) −2^(−κ·Z/m))/ ρ Where Κ is chosen to be around 1.75 §4. Implementation The data structure present in the geoip.c needs to be removed as it stores the IP address of the client. The data structure is shown below. struct clientmap_entry_t { HT_ENTRY(clientmap_entry_t) node; tor_addr_t addr; char *transport_name; unsigned int last_seen_in_minutes:30; unsigned int action:2; }; It then later needs to be replaced by a datastruture that contains the list of countries with the number of unique IP addrs seen for that country. The whole system can be represented by this diagram. ------------------ | Input IP Addr | ------------------ | | --------------------- | Determine Country | --------------------- | | ---------------------- | Determine Transport| ---------------------- | | ------------------------------ | Get salted hash of IP addr | ------------------------------ | | -------------------------- | Apply the formula | | on the hash obtained | -------------------------- | | --------------------------------------- | Increment that country's counter | | if the cardinality estimation | | is greater than the estimation | | done previously | --------------------------------------- §5. Security Considerations We might as well go ahead and implement this, but the thing to keep in mind is that implementing this would not protect a client's identity from a adversary completely. First thing to understand is that, an adversary that has gained access to a guard node or a bridge could still get the random value generated and deanonymize the client using brute force. Or even better, why would the adversary need that random value when she simply log all network connections coming into the compromised system? So, A thing to note is that this functionality would keep those clients anonymous who had connected to the compromised system in the past, but not those who will connect to it in the future. §6. References [1] https://en.wikipedia.org/wiki/Bloom_filter [2] https://www.chromium.org/developers/design-documents/rappor [3] https://research.neustar.biz/2013/04/02/sketch-of-the- day-probabilistic-counting-with-stochastic-averaging-pcsa/ ------------- Regards, Jaskaran Veer Singh

6 8

GSoC 17 | Name System API for Tor Onion Services
by Ivan Tham 02 Apr '17

02 Apr '17

I have created a proposal at http://dl.pickfire.tk/tor/proposal.md Feel free to review it and give comments, python script still WIP.

1 0