Re: [tor-dev] Defending against guard discovery attacks by pinning middle nodes

2014-11-12 Thread A. Johnson
>> As I was saying above, a fixed exit would allow compromise in the time >> it takes to begin surveillance (times three). We can likely do better >> than that. > > Ok, this was my assumption behind arguing for staggering these rotation > periods, too. I don't think that having a fixed exit is a g

Re: [tor-dev] Defending against guard discovery attacks by pinning middle nodes

2014-11-12 Thread Mike Perry
A. Johnson: > > > HS -> Guard_1 -> Guard_2 -> Guard_3 -> RP. > > > > The idea is that Guard_1 is a single node that you choose and keep > > for O(6 months, or as long as possible), but Guard_2 actually comes > > from a set of 3-6 or so nodes that you keep for O(weeks), and > > Guard_3 you rotate

Re: [tor-dev] Defending against guard discovery attacks by pinning middle nodes

2014-11-12 Thread A. Johnson
> It's interesting to reduce the HS path length, but that would reduce > the length of the chain that the adversary has to walk, which is bad :/ Yeah, security in this attack model pushes towards a long path. > The rendezvous model is a bit restricting isn't it :( Agreed, modifying path selectio

Re: [tor-dev] Defending against guard discovery attacks by pinning middle nodes

2014-11-12 Thread A. Johnson
By the way, I actually can think of a good reason to include multiple rotation speeds: to deal with both your uncertainty about surveillance speed and its randomness. Suppose that you think it takes somewhere between 3 hours and 1 month, but don’t have a much better guess than that. Then a good

Re: [tor-dev] Defending against guard discovery attacks by pinning middle nodes

2014-11-12 Thread George Kadianakis
George Kadianakis writes: > Mike Perry writes: > >> A. Johnson: >>> >> The idea would be that Guard_3 would rotate on the order of hours, >>> >> Guard_2 would come from a set that is rotated on the order of days >>> >> (based on the expected duration for the adversary to become >>> >> Guard_3),

Re: [tor-dev] Defending against guard discovery attacks by pinning middle nodes

2014-11-12 Thread George Kadianakis
Mike Perry writes: > A. Johnson: >> >> The idea would be that Guard_3 would rotate on the order of hours, >> >> Guard_2 would come from a set that is rotated on the order of days >> >> (based on the expected duration for the adversary to become >> >> Guard_3), and Guard_1 would rotate on the orde

Re: [tor-dev] Gap between advertised and utilized bandwidth

2014-11-12 Thread Ian Goldberg
On Wed, Nov 12, 2014 at 09:30:47AM +0100, Karsten Loesing wrote: > Hi George, > > I found this in my IRC backlog from November 7, 2014: > > 20:34 #tor-dev: < asn> karsten: how should one read these graphs > https://metrics.torproject.org/bandwidth.html#bandwidth-flags ? > 20:34 #tor-dev: < asn> k

Re: [tor-dev] tor packet handling

2014-11-12 Thread Andreas Krey
On Tue, 11 Nov 2014 15:07:38 +, Mohiuddin Ebna Kawsar wrote: > Hi, > > I want to develop extension(intrusion detection) for tor. for that i have > to extract TCP and IP header from packet. > I need to know where and how tor handle packet(TCP/IP). Nowhere. tor works with tcp connections provid

[tor-dev] Gap between advertised and utilized bandwidth

2014-11-12 Thread Karsten Loesing
Hi George, I found this in my IRC backlog from November 7, 2014: 20:34 #tor-dev: < asn> karsten: how should one read these graphs https://metrics.torproject.org/bandwidth.html#bandwidth-flags ? 20:34 #tor-dev: < asn> karsten: can the gap between two lines be interpreted as