[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: (FWD) Re: Proposal 171 (revised): Separate streams across circuits by connection metadata

On Fri, Jan 21, 2011 at 5:22 PM, Roger Dingledine <arma@xxxxxxx> wrote:
> [Forwarding because Nikita isn't subscribed at this address. -RD]
> ----- Forwarded message from owner-or-dev@xxxxxxxxxxxxx -----
> From: Nikita Borisov <nikita@xxxxxxxxxxxx>
> Date: Fri, 21 Jan 2011 16:00:44 -0600
> Subject: Re: Proposal 171 (revised): Separate streams across circuits by
>  connection metadata
> To: or-dev@xxxxxxxxxxxxx
> I have a suggestion: streams that have been explicitly designated for
> isolation by the use of different ports or usernames should also use a
> different set of guard nodes.  My thinking is that there have been
> attacks proposed in the past that can profile the set of guard nodes
> used by a client over time, as long as it's possible to externally
> link the connections (e.g., the connections contain a pseudonymous
> username in the cleartext).  If these attacks are used to profile two
> sets of externally linkable connections (i.e., two pseudonyms) and
> they come up with the same set of guards, that is a pretty strong
> indication that the pseudonyms are in fact linked to each other.  If I
> used a different port to separate the two pseudonyms, however, and Tor
> used a different guard set for each, this would not be a problem.
> Conversely, the advantage of using (the same set of) guard nodes
> disappears for streams that are not externally linkable, since the
> guards do not change the overall probability that each individual
> stream will be compromised.
> (I think it's harder to make the case that you want to do this based
> on implicit session indicators, since there's a chance that those
> streams will still be somehow linked, particularly if the indicators
> are short-lived, such as PIDs or source ports.)

This is a cool idea; I think it can be done orthogonally to the other
stream-separation stuff.  I've added a note to Proposal 171.

A possible issue is that number of  guard nodes used is visible to a
local adversary, who can use this to infer the number of different
session types that the user has.  I'm not sure how big of a problem
this is.