Re: [OT]RE: Unsubscribe

[grarpamp]

> Gone are the days where people ... reliably know what email headers are. :)

That I can excuse as part of the mass gui 2.0 effect. What baffles me
is that they knew they had to find and use some special interface to
subscribe. So why in the world would they think unsubscribing is any
different having already learned the former.

But hey, why knock on too hard, after all, this type of user generates
lots of free chaff for those who need it ;)
***
To unsubscribe, send an e-mail to majord...@torproject.org with
unsubscribe or-talkin the body. http://archives.seul.org/or/talk/

Re: [OT]RE: Unsubscribe

[László Monda]

On Thu, Sep 24, 2009 at 7:34 AM, Roger Dingledine  wrote:
> On Wed, Sep 23, 2009 at 10:28:32PM -0600, Jim McClanahan wrote:
>> Having seen this situation on this list multiple times, it occurs to me
>> that beyond "To", "From", and "Date", many people have probably never
>> seen the headers.  Most non-techies probably don't even know it exists.
>> I believe most GUI mail clients, by default, only show the abbreviated
>> version I just mentioned.  I know mine does.
>>
>> I don't know what the solution is, but I thought I would throw this out
>> there for people's consideration.
>
> Yep. Gone are the days where people on this list reliably know what
> email headers are. :)
>
> I just hacked^Wconfigured majordomo to put a footer on every mail to
> the list. We'll see if it works.

I don't understand why majordomo is used nowadays.  Mailman is so much
simpler and more intuitive to use.

>
> Thanks,
> --Roger
>
> ***
> To unsubscribe, send an e-mail to majord...@seul.org with
> unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
>



-- 
Laci  
***
To unsubscribe, send an e-mail to majord...@torproject.org with
unsubscribe or-talkin the body. http://archives.seul.org/or/talk/

private vs. public tor network ... any other options ?

[John Case]

I am aware that I may run a private Tor network if the speed or latency of 
the public Tor network is unacceptable to me.


I am also aware that failing to reach a critical mass of nodes and traffic 
will leave users' anonymity much more vulnerable to attack.


I don't know what the numbers are, in terms of minimum acceptable nodes or 
traffic, but I suspect that I don't want to arrange or

maintain it.

On the other hand, I do control a fair amount of infrastructure and 
bandwidth in multiple locations ... so it's very tempting to leverage 
those resources in a way that gives me tor-like anonymity, but without the 
(sometimes terrible) speed and latency.


Is there a middle ground ?  Is it possible for me to simultaneously 
contribute network resources to the public Tor network, allowing me to 
blend in like every other Tor user, yet at the same time somehow 
leveraging the specific resources I control to achieve faster speeds for 
my own use ?


Thanks.
***
To unsubscribe, send an e-mail to majord...@torproject.org with
unsubscribe or-talkin the body. http://archives.seul.org/or/talk/

Re: [OT]RE: Unsubscribe

[Roger Dingledine]

On Wed, Sep 23, 2009 at 10:28:32PM -0600, Jim McClanahan wrote:
> Having seen this situation on this list multiple times, it occurs to me
> that beyond "To", "From", and "Date", many people have probably never
> seen the headers.  Most non-techies probably don't even know it exists.
> I believe most GUI mail clients, by default, only show the abbreviated
> version I just mentioned.  I know mine does.
> 
> I don't know what the solution is, but I thought I would throw this out
> there for people's consideration.

Yep. Gone are the days where people on this list reliably know what
email headers are. :)

I just hacked^Wconfigured majordomo to put a footer on every mail to
the list. We'll see if it works.

Thanks,
--Roger

***
To unsubscribe, send an e-mail to majord...@seul.org with
unsubscribe or-talkin the body. http://archives.seul.org/or/talk/

Re: [OT]RE: Unsubscribe

[krishna e bera]

On Wed, Sep 23, 2009 at 10:28:32PM -0600, Jim McClanahan wrote:
> Having seen this situation on this list multiple times, it occurs to me
> that beyond "To", "From", and "Date", many people have probably never
> seen the headers.  Most non-techies probably don't even know it exists.
> I believe most GUI mail clients, by default, only show the abbreviated
> version I just mentioned.  I know mine does.


alternatively, majordomo v1 has a configuration option 
to bounce messages with such words in the subject or first few lines
to the list manager as administrative requests.

Re: [OT]RE: Unsubscribe

[Jim McClanahan]

downie - wrote:
> 
> You have to send to a different address. Instructions [to unsubscribe]
> are in the headers.

Having seen this situation on this list multiple times, it occurs to me
that beyond "To", "From", and "Date", many people have probably never
seen the headers.  Most non-techies probably don't even know it exists.
I believe most GUI mail clients, by default, only show the abbreviated
version I just mentioned.  I know mine does.

I don't know what the solution is, but I thought I would throw this out
there for people's consideration.

Jim

Re: Planning to build private network

[grarpamp]

Similarly...

I've fielded questions regarding using the public Tor for bulk data
transfer, backups, distributed file stores and the like. But it always
proves hard for me to resolve the impact in order to say go one way or
the other.
If they make a private Tor network, growth will be very slow because
there are not enough nodes to ensure anonymity. If they use public
Tor, it might get hammered. And it seems the long term survival of
using either pub/priv for this depend on whether users both felt anon
enough to give bandwidth and have enough bandwidth and the ethic to
give it. If they do, the math works out ok. If not, the net tanks.

And then there is the problem of authority servers.
It would be nice if Tor had an automated election system where that
function would roam about inside the Tor network itself as a self
sustaining agent. Because right now, I think one could cut them off
the net and take Tor with it.

RE: Planning to build private network

[John Case]

Does anyone have any comments or sugestions for the person that posted the 
below, about one month ago ?  I was very interested in this topic, but 
there were no follow-ups ...



-

I am currently planning to build a private TOR network for 50 users.  The 
goal of the network is to provide anonymous browsing and access to hidden 
services for the group while trying to avoid the low speeds seen in the 
public network.  The users will not be using the the network for file 
sharing or high bandwidth applications like streaming media.  The group 
currently uses the public network, and 12 are hosting relays.  The main 
complaint from the group is that the public network is too slow for 
comfortable use of some internet applications. (No big surprise)


I have a few questions.

1) Will a private network address the speed concerns if built properly?  I 
have read considerable amounts on the subject of TOR's speed, and 
understand that the number of relays is not the overriding concern.


2) If the answer to 1 is yes (i believe it is), what would be the optimum 
number of relays to ensure privacy and speed? Is there a formula that 
determines the number of relays need for X number of users, with a say a 3 
hop path? What about hidden services?  If there a rule of thumb for 
determining the number of exits to relays?


3) What would the minimum specs of a individual relay be? How much 
bandwidth per relay should we strive for?


4) Assuming we build it properly, and do not abuse it, what kind of speeds 
can we expect from the network?

[OT]RE: Unsubscribe

[downie -]

You have to send to a different address. Instructions are in the headers.
> Subject: Unsubscribe
> From: tim...@gmail.com
> To: or-talk@freehaven.net
> Date: Wed, 23 Sep 2009 17:07:45 +0200
> 
> Unsubscribe
> 
> 
> -- 
> The three fastest modes of communication ...
> telephone, telegraph and tell-a-woman. 
> 

_
Hotmail: Free, trusted and rich email service.
http://clk.atdmt.com/GBL/go/171222984/direct/01/

Re: Random chaff [was: more work for Grobbages]

[Jon McLachlan]

*sigh*

See below :)


On Sep 23, 2009, at 8:29 AM, Paul Syverson wrote:


On Wed, Sep 23, 2009 at 11:11:29AM -0400, Praedor Atrebates wrote:

It would appear that the tor network should include some timing
randomization and reordering of packets to thwart such analysis.
Not so much to really slow things down but enough to throw up
uncertainty in the packet analyses.



You're trying to turn it into a mix network.


That's something that exists in "that box" over there, not "Tor's  
box" ;)



The order uncertainty
doesn't matter at this level of latency.


AKA, as little of latency as possible... which is still quite a bit  
actually, thank you bittorrent :(



The Bauer et al. research I
mentioned showed how to do timing attacks based just on setting
up the circuit. You don't even need to send any data.


*shrugs*

If all clients in the network created Tor circuits of the same length,  
all at the same time, wouldn't that mangle that analysis of who's  
telescoping circuit-extension request is who's?  I know that's not  
what cover traffic does... but if Tor has some sort of "heart beat"  
that would make it more difficult to distinguish between which circuit- 
extension request is who's... that's only feasible because all clients  
have a stake in circuits, not the same for external-to-to requests,  
like webpages etc etc...




Whatever solution (if one even exists) is out there, most of
the straightforward ideas and many of the not so straightforward
ideas have already been extensively researched.


But not necessarily tested in the wild... Even the Bauer et al.  
demonstrates those ideas in a fake Tor network, yes, on recommendation  
from Tor not to do the experiment in Tor, but still.  And on PL, the  
VM environment is particularly prone to latency, so of course timing  
analysis attacks will stick out like a sore thumb...


so there might actually be something to deploying that exp on the real  
network...



Cf.


what does that mean?  :)


the papers
Nick and I mentioned before and others in the Freehaven anonbib.

aloha,
Paul

Re: Random chaff [was: more work for Grobbages]

[Paul Syverson]

On Wed, Sep 23, 2009 at 11:11:29AM -0400, Praedor Atrebates wrote:
> It would appear that the tor network should include some timing
> randomization and reordering of packets to thwart such analysis.
> Not so much to really slow things down but enough to throw up
> uncertainty in the packet analyses.


You're trying to turn it into a mix network. The order uncertainty
doesn't matter at this level of latency. The Bauer et al. research I
mentioned showed how to do timing attacks based just on setting
up the circuit. You don't even need to send any data.

Whatever solution (if one even exists) is out there, most of
the straightforward ideas and many of the not so straightforward
ideas have already been extensively researched. Cf. the papers
Nick and I mentioned before and others in the Freehaven anonbib.

aloha,
Paul

Re: Random chaff [was: more work for Grobbages]

[Praedor Atrebates]

It would appear that the tor network should include some timing randomization 
and reordering of packets to thwart such analysis.  Not so much to really slow 
things down but enough to throw up uncertainty in the packet analyses.

On Wednesday 23 September 2009 10:59:03 am Paul Syverson wrote:
> On Wed, Sep 23, 2009 at 10:01:07AM -0400, Brian Mearns wrote:
> > 
> > So, if I understand this correctly, a correlation attack works (on a
> > very basic level) by noticing that Alice sent a message to Bob (a
> > known Tor node) at time X, and Dave (another known Tor node) sent a
> > message to Wally (a web server) at time X+e, where e is about how long
> > we would expect it to take for the onion to be routed. Is that more or
> > less the idea?
> 
> Yes. But packet counting can also play a role. Cf, 
> "Passive Attack Analysis for Connection-Based Anonymity Systems"
> at http://freehaven.net/anonbib/index.html#SS03
> 
> > 
> > It seems like determining e (time to route the packet) with any degree
> > of precision would be pretty difficult, so is this really a big
> > problem? (or is that still being debated?) 
> 
> It's not. Cf. my "Locating Hidden Servers"
> http://freehaven.net/anonbib/index.html#hs-attack06
> wherein we had zero false positives on any timing attacks conducted
> in finding hidden services, which generally was very quick.
> (That such attacks existed were known for years. That they were not
> just possible but so fast and effective using merely a single
> node in the network was the reason that guard nodes were introduced
> into the Tor network.)
> 
> And building on that see, "Low-Resource Routing Attacks Against Tor"
> http://freehaven.net/anonbib/index.html#bauer:wpes2007
> where timing attacks with epsilon false positives
> were based simply on circuit setup and were shown on general
> Tor circuits, not just for hidden services.
> 
> > On the other hand, if an attacker could monitor a good number of
> > nodes, wouldn't it be fairly easy to determine each three-node
> > circuit segment (like Alice, to Bob, to Charlie) and trace the whole
> > thing end-to-end? It seems like this could be defeated with a more
> > intelligent type of "chaff", where the receiving relay generates N
> > random dummy onions (with an appreciable circuit length) for each
> > onion it receives, and then sends all N+1 into the network in a
> > random order.
> > 
> 
> There's been a lot of research on this. I think Nick pointed at
> some. Cf. the anonbib.
> Research against timing attacks continues. (I'm doing some myself.)
> But so far, any "chaff" strategy in the literature is both too
> expensive and not at all effective against active attacks on
> general low-latency systems for wide use, such as Tor.
> 
> HTH,
> Paul
> 
> 

-- 
“We can have a democratic society or we can have the concentration of great 
wealth in the hands of the few. We cannot have both.” 
— Louis Brandeis, Supreme Court Justice, 1916-1939

Unsubscribe

[Tim Hendrik]

Unsubscribe


-- 
The three fastest modes of communication ...
telephone, telegraph and tell-a-woman. 



signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil

Re: Random chaff [was: more work for Grobbages]

[Paul Syverson]

On Wed, Sep 23, 2009 at 10:01:07AM -0400, Brian Mearns wrote:
> 
> So, if I understand this correctly, a correlation attack works (on a
> very basic level) by noticing that Alice sent a message to Bob (a
> known Tor node) at time X, and Dave (another known Tor node) sent a
> message to Wally (a web server) at time X+e, where e is about how long
> we would expect it to take for the onion to be routed. Is that more or
> less the idea?

Yes. But packet counting can also play a role. Cf, 
"Passive Attack Analysis for Connection-Based Anonymity Systems"
at http://freehaven.net/anonbib/index.html#SS03

> 
> It seems like determining e (time to route the packet) with any degree
> of precision would be pretty difficult, so is this really a big
> problem? (or is that still being debated?) 

It's not. Cf. my "Locating Hidden Servers"
http://freehaven.net/anonbib/index.html#hs-attack06
wherein we had zero false positives on any timing attacks conducted
in finding hidden services, which generally was very quick.
(That such attacks existed were known for years. That they were not
just possible but so fast and effective using merely a single
node in the network was the reason that guard nodes were introduced
into the Tor network.)

And building on that see, "Low-Resource Routing Attacks Against Tor"
http://freehaven.net/anonbib/index.html#bauer:wpes2007
where timing attacks with epsilon false positives
were based simply on circuit setup and were shown on general
Tor circuits, not just for hidden services.

> On the other hand, if an attacker could monitor a good number of
> nodes, wouldn't it be fairly easy to determine each three-node
> circuit segment (like Alice, to Bob, to Charlie) and trace the whole
> thing end-to-end? It seems like this could be defeated with a more
> intelligent type of "chaff", where the receiving relay generates N
> random dummy onions (with an appreciable circuit length) for each
> onion it receives, and then sends all N+1 into the network in a
> random order.
> 

There's been a lot of research on this. I think Nick pointed at
some. Cf. the anonbib.
Research against timing attacks continues. (I'm doing some myself.)
But so far, any "chaff" strategy in the literature is both too
expensive and not at all effective against active attacks on
general low-latency systems for wide use, such as Tor.

HTH,
Paul

Re: Random chaff [was: more work for Grobbages]

[Brian Mearns]

On Wed, Sep 23, 2009 at 3:38 AM, Nick Mathewson  wrote:
> On Fri, Sep 18, 2009 at 10:19:17PM -0400, Ted Smith wrote:
>> On Fri, 2009-09-18 at 04:25 -0400, grarpamp wrote:
>> > Nodes usually have a max bandwitch set.
>> > Nodes often comsume less than this.
>> > All node to node traffic is encrypted.
>> > Perhaps implement a random stream generator
>> > that only runs when it or its chosen path has
>> > free bandwidth, tags its traffic as chaff, pipes
>> > it through some number of nodes, or if it has
>> > idle neighbors, and ultimtely sink it somewhere.
>> > It would be even harder to follow an actual client
>> > dl/ul stream if things were maybe udp with the stream reassembly
>> > info inside each onion wrapped cell. Or something
>> > like that. No doubt this is old ideas.
>>
>> Indeed it is, and it's my understanding that this doesn't really work.
>> More astute minds than I can explain in full, but you can render this
>> sort of safeguard useless quite easily.
>
> The issue with padding isn't that it doesn't work at all, but that it
> doesn't work well enough to do any good.  Last I checked, the state of
> the art in low-volume padding could slow down correlation attacks by
> 10-50%, depending on how you're counting.
>
> This sounds good until you think about how fast correlation attacks
> actually are.  If a correlating attacker (one watching both ends of
> the communication) needs only a second of traffic to link sender and
> receiver, then forcing him to collect an extra half-second of traffic
> doesn't actually help the user very much, assuming that the user
> intends to use Tor for more than a second and a half.
>
> What would need to change for padding to become useful? If it turns
> out that correlation attacks are far more difficult than the research
> community thinks, or if somebody comes up with a padding approach that
> actually delays correlation enough[**], I think we should come back
> to the question.
>
> [*] You can do high-cost methods that defeat correlation[***] pretty
>    easily: constant-rate traffic is one of them.  There's a FAQ
>    entry about why constant-rate traffic probably won't work in
>    the wild:
>      http://wiki.noreply.org/noreply/TheOnionRouter/TorFAQ#YouShouldPad
>
> [**] What's "enough"?  I'd say "the lifetime of a circuit," but I
>      might be wrong.
>
> [***] But you'd still need to worry about active attacks in this case.
>
>
> peace,
> --
> Nick
>

So, if I understand this correctly, a correlation attack works (on a
very basic level) by noticing that Alice sent a message to Bob (a
known Tor node) at time X, and Dave (another known Tor node) sent a
message to Wally (a web server) at time X+e, where e is about how long
we would expect it to take for the onion to be routed. Is that more or
less the idea?

It seems like determining e (time to route the packet) with any degree
of precision would be pretty difficult, so is this really a big
problem? (or is that still being debated?) On the other hand, if an
attacker could monitor a good number of nodes, wouldn't it be fairly
easy to determine each three-node circuit segment (like Alice, to Bob,
to Charlie) and trace the whole thing end-to-end? It seems like this
could be defeated with a more intelligent type of "chaff", where the
receiving relay generates N random dummy onions (with an appreciable
circuit length) for each onion it receives, and then sends all N+1
into the network in a random order.

Then again, I may have completely missed the boat on this whole
correlation attack thing.

-Brian

-- 
Feel free to contact me using PGP Encryption:
Key Id: 0x3AA70848
Available from: http://keys.gnupg.net

Re: Random chaff [was: more work for Grobbages]

[Nick Mathewson]

On Fri, Sep 18, 2009 at 10:19:17PM -0400, Ted Smith wrote:
> On Fri, 2009-09-18 at 04:25 -0400, grarpamp wrote:
> > Nodes usually have a max bandwitch set.
> > Nodes often comsume less than this.
> > All node to node traffic is encrypted.
> > Perhaps implement a random stream generator
> > that only runs when it or its chosen path has
> > free bandwidth, tags its traffic as chaff, pipes
> > it through some number of nodes, or if it has
> > idle neighbors, and ultimtely sink it somewhere.
> > It would be even harder to follow an actual client
> > dl/ul stream if things were maybe udp with the stream reassembly
> > info inside each onion wrapped cell. Or something
> > like that. No doubt this is old ideas.
> 
> Indeed it is, and it's my understanding that this doesn't really work.
> More astute minds than I can explain in full, but you can render this
> sort of safeguard useless quite easily.

The issue with padding isn't that it doesn't work at all, but that it
doesn't work well enough to do any good.  Last I checked, the state of
the art in low-volume padding could slow down correlation attacks by
10-50%, depending on how you're counting.

This sounds good until you think about how fast correlation attacks
actually are.  If a correlating attacker (one watching both ends of
the communication) needs only a second of traffic to link sender and
receiver, then forcing him to collect an extra half-second of traffic
doesn't actually help the user very much, assuming that the user
intends to use Tor for more than a second and a half.

What would need to change for padding to become useful? If it turns
out that correlation attacks are far more difficult than the research
community thinks, or if somebody comes up with a padding approach that
actually delays correlation enough[**], I think we should come back
to the question.

[*] You can do high-cost methods that defeat correlation[***] pretty
easily: constant-rate traffic is one of them.  There's a FAQ
entry about why constant-rate traffic probably won't work in
the wild:
  http://wiki.noreply.org/noreply/TheOnionRouter/TorFAQ#YouShouldPad

[**] What's "enough"?  I'd say "the lifetime of a circuit," but I
  might be wrong.

[***] But you'd still need to worry about active attacks in this case.


peace,
-- 
Nick