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

Re: same first hops

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         *
**********************************************************************