same first hops

[Anon Mus]

Scott Bennett wrote:
>      Well, technically speaking, I guess that's true.  However, unless I'm greatly mistaken, the exit end of a circuit will compress any data coming into it to be relayed back to the client and will uncompress anything arriving from the client to be sent out from the exit.  Given that the attacker might observe data in the clear going into the exit or coming out of it and could perform the same compression in order to know the length of the encrypted data, the attacker might be able to pull that off.  Another complication for the attacker to deal with is the fact that a link between
> the client and an entry node may support multiple circuits, and each
> circuit may support multiple streams, all of which are multiply encrypted and whose data cells are commingled with the data cells of the others at the client end with no obvious way of distinguishing between the cells of one thread and the cells of any other thread traversing that particular link.
>   

Does this already happen?
 
>      However, in order to match the length up with whatever is sent/received
> by the suspected client, wouldn't the attacker need to make an assumption or
> two about the circuit length?  If so, then introducing randomly varying
> circuit lengths ought to obfuscate things considerably for the attacker.
>   

This has been suggested many times.. but never, to my knowledge, 
implemented.

Its one way to add real entropy to the tor network traffic, circuits 
(specified user setting min max hops) could randomly vary between say 
3..5 hops.

Also 1 and 2 hop circuits would be useful (& add more entropy) for where 
a person only wanted a simple exit ip proxy. This is useful nowadays for 
2 reasons,

1.  where some forums have "bad","nuisance" ip blocking lists. Some 
clever forum admins (contrary to forum rules) will put someones ip on 
this list to (illegally) stop them posting a reply, usually if the admin 
is abusing their power and losing some argument with someone on the 
forum. When challenged this admin will claim they had nothing to do with 
it and that it was the "automated protection mechanism". So to be able 
to have a large number of simple proxies to hand immediately is very useful.

2.  for anonymously seeding/downloading  torrents. Now, before you all 
shout, you must realize its getting more difficult out there. People are 
getting sent huge fines for just downloading a movie they will junk the 
next day, based on their IP addy. Potentially, torrent traffic could 
provide a lot of cover for torland users. 3 or more hops is far too 
excessive. 1 (or 2) hops would be enough. It not needed for most 
torrents (eg legal porn) and 1 hop is not going to protect you from law 
enforcement.


>      Another possible way to complicate things for the attacker would be a
> variant of something has already been proposed, namely, using multiple data
> cell sizes within the circuit.  As I understand it, the suggestions so far
> have been directed toward efficiency, e.g., sending long cells when there
> are enough data to exceed the payload limits of short cells.  However, if
> short cells were randomly used when there are enough data for long cells,
> then the significance to the attacker of the distinction between long and
> short cells would be somewhat reduced.  Tossing in occasional padding at
> random to produce a long cell that might have either had only minimally
> more payload than a short cell or even data for which a short cell would
> have been adequate ought to augment the attacker's obstacles.  If more
> than two cell lengths were used, then these techniques ought to become even
> more effective against attackers.
>   

Also been suggested before.

Perhaps it might be possibly to make very packet exactly the same size. 
Or at least a range (large medium small) of exact size packets. So they 
could not be told apart according to their exact data.

>      A third possibility might be to do at the tor level something that
> is already supported at the data link level in the BSDs and perhaps LINUX,
> namely, to use multiple physical links (circuits in the case of tor) to
> split the traffic load of a data link (stream in the case of tor) across
> multiple physical links.  The downside of this method, of course, is that
> it multiplies the risk of a broken stream due to a tor node failure or
> lower-level failure.  OTOH, it might also frequently and significantly
> speed up large file transfers through tor.
>   

Also been suggested before.

>      If a new feature were added to tor's internal protocol that would
> allow handing off a thread from one circuit to another, then a further
> enhancement could be made because it would be handled entirely at the tor
> level.  For example, a thread supported by (i.e., spread across) multiple
> tor circuits could be shifted across a frequently changing set of circuits
> between the client and the exit server, all under the control of the tor
> client.
Used in i2p?

>   For a fixed circuit length, such as the constant length of 3 that
> is currently the standard in tor, the entry node and/or the middleman in
> each circuit could be replaced from time to time.  A tor network that used
> all of these methods (including variable-length circuits) ought to provide
> a major nightmare (not to mention processing demands) for even a heavily
> funded and equipped attacker to untangle by the use of timing/sizing
> measurements.  (It might also be overkill, I suppose.:-)
>
>
>                                   Scott Bennett, Comm. ASMELG, CFIAG
> **********************************************************************
> * Internet:       bennett at cs.niu.edu                              *
> *--------------------------------------------------------------------*
> * "A well regulated and disciplined militia, is at all times a good  *
> * objection to the introduction of that bane of all free governments *
> * -- a standing army."                                               *
> *    -- Gov. John Hancock, New York Journal, 28 January 1790         *
> **********************************************************************
>
>