Re: [tor-relays] 60 new neu.edu relays in 16 minutes

[privacy@xxxxxxxxxxx]

> On Aug 11, 2017, at 4:50 AM, Roger Dingledine <arma@xxxxxxx> wrote:
> 
> On Thu, Aug 10, 2017 at 07:53:03PM -0400, privacy@xxxxxxxxxxx wrote:
>> We are using Online S.a.s because it it is cheap (I guess it's the same reason why others use it). We will check in the next couple of days if there is an alternative low cost provider.
> 
> If I understand the threat model for your "every relay encrypts its
> share, and then you do threshold decryption of the aggregate total"
> design, having even a few relays at some other ISP would make it a lot
> harder for the one ISP to attack all of the shares, right?

It is slightly different but basically the same spirit. We use a group key such that none of the three teams can decrypt alone. One key thing is that each relay only has the group public key and encrypts the counters. So the logged counters are encrypted and neither the ISP neither one/two of the teams can decrypt them. Another important point is that besides the encrypted counters the information available to the relays is the same as for any other relay running on the ISP.  Here, whatever the ISP can do to our relays, he can also do to the other relays running on its infrastructure.

> Maybe you can spin up one relay at each research institution, for
> some diversity? :)

Based on this discussion, we have started the process to move 20 relays to at least one of the institutions. Hopefully, this increase diversity in terms of capacity and trust.

> That said, I'm not too worried here. The information you're protecting in
> this case isn't by itself that dangerous to publish, so the complicated
> privcount scheme is a great layer to add on top but the world doesn't
> end if it fails.

Yes.

> So if you wanted to add some more relays to make the "distributed trust"
> angle more distributed, great, and if you don't, we can treat it as a
> good lesson to learn for next time.

Yes, we are working on it.

>> We have also limited our bandwidth but can increase it if more people express interest and it can help (we didn???t want to look like we are trying to attract/intercept traffic).
> 
> Interesting question! I can see pros and cons.
> 
> The two big topics are:
> 
> 1) If you raise the bandwidth on each of them by enough, then they'll end
> up getting the Guard flag, so you'll attract clients directly, and your
> relays will be in a better position to attack them.

Yes, and we might ourselves become a more desirable target.

> 2) If you raise the bandwidth, then the total fraction of the Tor network
> that your relays handles go up.
> 
> I'm tempted to say "as long as you stay at 2-3% of the total network
> you'll be fine”,

That sounds good. We’ll keep it in mind.

> but the fact that they're all at an already overpopulated
> ISP makes me pause.

Hopefully, the planned relays will help. In anycase, we will most likely keep the bandwidth low for now.

Guevara


_______________________________________________
tor-relays mailing list
tor-relays@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays