Re: [tor-dev] Proposal 246: Defending Against Guard Discovery Attacks using Vanguards

I agree with most of what you said regarding the threat of a targeted observer. What I disagree with is that an adversary running his own relays is less of a threat. Running relays is trivial, and running 5% of the guards is fairly cheap (I estimate ~$3000/month (please ask for details)). If you

Re: [tor-dev] Proposal: Merging Hidden Service Directories and Introduction Points

> On Jul 20, 2015, at 4:03 PM, John Brooks wrote: > > A. Johnson wrote: > >>> This proposal doubles the default number of IPs and reduces the “cost" >>> of being an IP since the probability of being selected is no longer >>> bandwidth-weighted. Is this a fair tradeoff for the performance >>> i

Re: [tor-dev] Proposal: Merging Hidden Service Directories and Introduction Points

>> That seems easy to fix. Make the number of Introduction Points the same as >> it was before and make them be selected in a bandwidth-weight way. There is >> no cost to this. You need IPs to be online, and so whatever number was used >> in the past will yield the same availability now. And ban

Re: [tor-dev] Proposal: Single onion services

Hello, Nice, concise proposal! I’ve been meaning for a while to send some comments: Overall: 1. This proposal doesn’t allow you to run a single-onion service if your server is behind NAT. It might be useful to include an option for the SOS to create persistent connections to some guards

Re: [tor-dev] Simplifying load balancing by removing Guard+Exit?

> This would be a 24% decrease in the number of Guards, which seems ok, > particularly if they’re not good at being guards anyway. > (Counts from the 2015-09-24 21:00:00 microdesc consensus in my local Tor > Browser data folder.) Relays with the Guard+Exit flags have had zero weight as guards fo

Re: [tor-dev] Proposal 247 (Hidden Service Vanguards) Overhaul

Hi Mike, Here are some specific comments on the proposal, most of which I didn’t mention at the session yesterday. Sec. 2: “When a hidden service picks its guard nodes, it also picks two additional sets of middle nodes `second_guard_set` and `third_guard_set` of size NUM_SECOND_GUARDS and NUM_

[tor-dev] Guidelines and processes for ethical Tor research

Hello, Today at the Tor developers’ meeting, we had a discussion about how to help ensure that Tor research is done ethically. We developed a set of general guidelines for ethical Tor research, and we sketched out a process that researchers should follow if they want to do work on the live Tor

Re: [tor-dev] ResearchEthics

> https://trac.torproject.org/projects/tor/wiki/doc/ResearchEthics > > Any number of problems and obstacles to legitimate > research areas exist with this… I would be interested in any others that you have other than the one you bring up below. > " > It is not acceptable to run an HSDir, harves

Re: [tor-dev] Onion Services and NAT Punching

NAT-punching in single-onion services seems to me to be a clear functionality improvement with an unclear effect on security. The NAT-punching protocol that we settled on at the dev meeting was: 1. The single-onion service (SOS) maintains a direct connection to an IP. 2. A client does an HSDi

Re: [tor-dev] ResearchEthics

Hello Rishab, > I've been meaning to respond to this for a while. Thanks for your thoughts. > For what it's worth, I completely disagree that outright "banning" of certain > data collection is the right answer here. There should be a standard "let's > weigh the risks vs. the benefits and make

Re: [tor-dev] ResearchEthics

> The idea of that list is to provide specific activities for which the costs > are judged not to outweigh the benefits. Sorry, that should have been "for which the costs are judged *to* outweigh the benefits”. Also, I should have mentioned that even being on that list wouldn't necessarily be

Re: [tor-dev] ResearchEthics

group? Aaron > On Oct 8, 2015, at 10:33 AM, Aaron Johnson > wrote: > >> The idea of that list is to provide specific activities for which the costs >> are judged not to outweigh the benefits. > > Sorry, that should have been "for which the costs are judged *to* o

Re: [tor-dev] Support for mix integration research

Hello Katharina, Sounds like a great project. I have a couple of suggestions: 1. Consider how to use mixing to anonymize Tor’s name resolution system. Currently, clients connect to onion service by first resolving the onion address (e.g. xyzblah.onion) to a descriptor using a distributed hash

Re: [tor-dev] Tor Browser downloads and updates graphs

>> Here's >> >> the same graph with more data, more request types, and of course a >> lot more shininess: >> >> https://tor-metrics.shinyapps.io/webstats/ >> ... > If you feel that's interesting enough, would it be possible to also > add the number of

Re: [tor-dev] Tor Browser downloads and updates graphs

> > Good thinking! I summarized the methodology on the graph page as: The > graph above is based on sanitized Tor web server logs [0]. These are a > stripped-down version of Apache's "combined" log format without IP > addresses, log times, HTTP parameters, referers, and user agent strings. ... >

Re: [tor-dev] Tor Browser downloads and updates graphs

> > Log files are sorted as part of the sanitizing procedure, so that > request order should not be preserved. If you find a log file that is > not sorted, please let us know, because that would be a bug. That’s great! It just appeared ordered in that multiple related requests appeared in seque

Re: [tor-dev] Proposal 273: Exit relay pinning for web services

A concern with this proposal that I have not seen mentioned is that exit pinning would cause the Tor path itself to leak more information about the intended destination. For example, a destination could (possibly without malicious intent) pin a single exit that is otherwise unlikely to be used.

Re: [tor-dev] Anonymous Local Count Statistics Using PCSA - GSoC

Hi Samir, It is my understanding that the Tor metrics team plans to handle this problem in a different way. IPs are kept in memory to provide statistics about users’ countries, and so they will instead just keep the country statistics directly. That is, a counter will be kept for all countries,

Re: [tor-dev] Anonymous Local Count Statistics Using PCSA - GSoC

> These statistics not just tell about the user's country but also keep a > track of unique IP addresses connecting from each country. This is > needed so as to present more realistic stats. If we increment counter on > any IP address instead of unique IP address then the statistics would > also re

Re: [tor-dev] Anonymous Local Count Statistics Using PCSA - GSoC

” tab on <https://metrics.torproject.org/userstats-relay-country.html>. Best, Aaron > On Apr 2, 2017, at 8:51 AM, Veer Kalantri wrote: > > about which stats are you talking Aaron? > > > On Sun, Apr 2, 2017 at 5:45 PM, Aaron Johnson <mailto:aaron.m.john...@nrl.

Re: [tor-dev] Anonymous Local Count Statistics Using PCSA - GSoC

] Florian Tschorsch and Björn Scheuermann, "An algorithm for privacy-preserving distributed user statistics”, Computer Networks 57 (2013). > On Apr 2, 2017, at 9:07 AM, Aaron Johnson > wrote: > > Sorry, I should have been more clear there. Tor Metrics estimates the total >

Re: [tor-dev] Proposal xyz : Count Unique IP addresses in an anonymous way

> We should also consider how this proposal would interact with other > proposed secure aggregation solutions, like Privcount [1] and/or some > other kind of PrivEx [2]. I'd like to hear what the designers of > those ideas think of this one. As you know, PrivCount is a secure aggregation system.

Re: [tor-dev] PrivCount - Draft of secret-sharing specification

Hello, This appears to be a sketch of Shamir secret sharing, which will be just one tool used in the PrivCount system. For example, it is missing how relays (aka Data Collectors) maintain counters, how aggregators (aka Share Keepers) aggregate counters, and how secret sharing is used among thos

Re: [tor-dev] Proposal 288: Privacy-Preserving Statistics with Privcount in Tor (Shamir version)

t;>. > On Dec 12, 2017, at 9:04 PM, teor wrote: > >> >> On 2 Dec 2017, at 07:26, Nick Mathewson > <mailto:ni...@torproject.org>> wrote: >> >> Filename: 288-privcount-with-shamir.txt Title: Privacy-Preserving Statistics >> with Privcount in To

Re: [tor-dev] Proposal 288: Privacy-Preserving Statistics with Privcount in Tor (Shamir version)

>> in Prio, servers use a generic secure multi-party computation (MPC) protocol >> to compute the circuits. If Tor is going to do that, why not just run a >> generic MPC protocol over all of the inputs? Doing so would allow Tor >> statistics aggregations to be robust to inputs that are likely “i

Re: [tor-dev] Proposal Waterfilling

Hello, I recently took the time to read the waterfilling paper. I’m not sure its a good idea even for the goal of increasing the cost of traffic correlation attacks. It depends on whether it is easier for an adversary to run many small relays of total weight x or a few large relays of total wei

Re: [tor-dev] Proposal Waterfilling

Hello friends, > 1) The cost of IPs vs. bandwidth is definitely a function of market offers. > Your $500/Gbps/month seems quite expensive compared to what can be found on > OVH (which is hosting a large number of relays): they ask ~3 euros/IP/month, > including unlimited 100 Mbps traffic. If we

Re: [tor-dev] Proposal Waterfilling

>> 1) The cost of IPs vs. bandwidth is definitely a function of market offers. >> Your $500/Gbps/month seems quite expensive compared to what can be found on >> OVH (which is hosting a large number of relays): they ask ~3 euros/IP/month, >> including unlimited 100 Mbps traffic. If we assume that

Re: [tor-dev] PrivCount and Prio IRC Meeting

Hello, I won’t be able to be at this meeting, but I would like to make some comments: 1. Prio’s zero-knowledge proofs (i.e. SNIPs) are not secure against a single malicious server. If you are using them the decide whether or not to include a given input, then a malicious server can cause good