Re: same first hops

[Scott Bennett <bennett@xxxxxxxxxx>]

     On Thu, 09 Oct 2008 10:11:26 +0000 Anon Mus
<my.green.lantern@xxxxxxxxxxxxxx> wrote:
>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?

     Does what already happen?  People attempting this sort of attack?  Who
knows, except for the putative attackers?  But given the illegal behavior of
the U.S. government under the current, criminal regime, I'd say it's likely.
If you further consider the fact that essentially *all* Internet traffic that
originates in, terminates in, or merely passes through any facilities in the
U.S. is captured by the U.S. government, this crime syndicate seems most
likely to have some success at such attacks if it wants to.  China is probably
alsoa good bet and for some of the same reasons.  Russia?  Maybe, but they
might not think it was yet worth their trouble.  The U.K.?  Also, maybe, but
keep in mind the requirement of being able to see both ends out of many, many
possible ends to circuits in order to have a chance of a successful attack.
Another possibility might be Japan, though that one strikes me as a tad
unlikely at this point.
     Or, if you were referring to how tor works, please see

	http://www.torproject.org/overview.html.en

I suppose I should clarify what I wrote above by pointing out that all
streams sharing a circuit share that circuit's onion, as opposed to having
a different onion for each stream.  But their data cells are, of course,
intermingled.
> 
>>      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.

     I would rather set 4 hops as the low end of the route length because
of certain things that have been posted to this list in the past that suggest
that 3 is inadequate.  So I guess I'd go for 4 to 6 or 7 as a good range.
OTOH, from a randomization point of view, the more the better.  The downside
there, of course, is that each additional hop introduces one more potential
point of circuit failure, lengthens response times, and generally eats up
more capacity of the tor network.
     While we're on this subject, I'd like to point out a problem with tor's
current data rate capacity testing during server initialization.  In order
to get some initial observations of the available data rates over a server's
network connections, tor builds a few (3?) test circuits that make a loop
from itself into the tor network and then back to itself.  At present it
uses the normal route length to do this, which can give a drastically low
measurement.  A better way would seem to be to use a single hop, i.e., a
circuit that goes to one other relay and the back to its source.  That may
still provide a low estimate however, so the value obtained from a single
hop test probably ought to be doubled for use as an estimate of the data rate
capacity of the server that is being initialized.
>
>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.
>
     As I understand things, if you write your own controller, it can direct
the construction of circuits to any route length and sequence of nodes that
you wish to use.  However, I suppose something akin to the LongLivedPorts
directive in torrc might be useful to those of us who aren't likely to write
a specialized controller to specify certain ports for which the client side
of tor should use a different, specified route length when constructing new
circuits.
>
>>      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.

     That is exactly what has been implemented (same size) and proposed (fixed
set of sizes--two to be precise) already.  That is partly why I mentioned it.
However, I don't think the random use of "wrong"-sized cells was proposed
before, a trick that could be considered as contrary to the cause of efficiency
for which the two-cell-size feature was proposed.  Obviously, only the client
and the exit could be deciding such things, while the middlemen would simply
be passing along whatever they were given because they could not know whether
some part of those cells were padding, much less how *much* padding were
present in a cell.
>
>>      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.

     Oh?  I guess I must have missed that.  Is there a particular proposal
number that I should look up to read about it?
>
>>      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?

     I don't really know anything about that, so I can't answer your
question.
     For tor, though, something of the sort has been proposed, but in the
context of handling circuit failures or as a way of switching exits in
mid stream.  It seems to me that exits cannot be switched because of how
TCP works, but that any entry or middleman node ought to be replaceable for
a stream, provided there were some method for the client to direct the
changeovers.  It would also not be necessary to expire a circuit that a
stream were being moved off of, though it might first be necessary to build
a new circuit onto which to move the stream, perhaps using the same criteria
tor now uses for deciding when to build a new circuit to satisfy a request
for a new stream, as opposed to putting the new stream onto an existing
circuit..
>
>>   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         *
**********************************************************************