Re: (micro)payments for anonymous routing in Tor?

[Scott Bennett <bennett@xxxxxxxxxx>]

     On Wed, 24 Sep 2008 03:44:39 -0400 "Josh Albrecht" <thejash@xxxxxxxxx>
wrote:
>> * payments turn it into a service with an expected outcome.  Assumably
>> (among others) that is 1) your anonymity is maintained and 2) your payment
>> is completed successfully.  What happens _when_ something goes wrong? As of
>> now, the first thing that Tor says is "This is experimental software. Do not
>> rely on it for strong anonymity. " It would have to add, "Do not rely on
>> this to successfully route your financial transactions" and while the first
>> is a warning most can accept, the second may really scare us.
>
>This came up on IRC as well.  Someone pointed out that the paper's
>assumption of "honest but curious" banks might not be valid (ie, the
>bank might cheat).  However, there are a few counter-arguments to that
>that I see.
>
>For the S-coins, it will be immediately obvious to a relay that the
>bank is cheating, because the relay can validate whether the payment
>is good or not on its own.  For the A-coins, the answer is trickier.
>The relays can still check the validity of the payment, but the client
>could be "double-spending".  If the bank pays A-coins even in the case
>of double-spending, the bank can never cheat.  The downside is that
>anonymous clients can then cheat to get slightly more value for
>A-coins than they put in.  This is a serious problem because it would
>allow the client to pay multiple relays that they control, essentially
>duplicating their money for free.
>
>Thus, the bank must decline all payment for double-spent A-coins, or
>at least allow only one payment for any A-coin.  However, clients can
>still validate that the bank is not cheating by withdrawing and
>depositing A-coins at any time in an attempt to catch the bank
>cheating.  This is more of an economic argument--the bank has an
>incentive to maintain user trust so that it can continue to do
>business.  The value gained by cheating some users of A-coins would
>likely be less than the expected gain from NOT having to worry about
>the risk of someone demonstrating that the bank is cheating.
>
>Also, the values at stake are:  1.  very small, and 2.  greater than
>the current profit of zero for relay operators.  It's not that relay

     Relay operators already get an advantage that client-only users
don't have:  their own traffic is mingled into relay traffic at the
outset, often making it difficult for an observer to know that the relay
operator is even conducting any client operations him/herself.
     I have to comment here that all of the foregoing discussion gives me
the impression that implementing such a system would add considerable
overhead to the tor network.  If people are complaining about slowness
now, then why would anyone want to add to the overhead?  The total
throughput of the tor network would not be increased by a priority system,
and it's conceivable that it might be decreased a bit due to the extra
overhead, especially where that overhead incurs extra network traffic.

>operators have to rely on Tor for their financial security--they
>could, with this scheme, make some modest amount to cover their costs.
> No single relay operator should ever have a significant amount of
>money in the system that could possibly be at risk.
>
>> On Wed, Sep 24, 2008 at 12:05 AM,  <tor-operator@xxxxxxxxxxxxx> wrote:
>> How do you pay anonymously yet have the system fairly permit "paid" traffic to
>> have higher priority?  With anonymity intact, how do you audit and enforce
>> this policy?
>>
>
>I think your first question was about how to ensure that giving
>priority to certain traffic does not introduce any new attacks against
>anonymity?  In that case, I'm not sure, but it is not at all clear to
>me that this would decrease anonymity.  Does anyone see such an
>attack?

     Well, I don't know about any actual method of attack, but using such
a system would seem to reduce anonymity by partitioning traffic into traffic
belonging to those who can "pay" (relay operators) and traffic belonging to
those who cannot (non-relay (i.e., client-only) operators).  The two groups
are likely to be unequal in size, probably with the client-only group being
the larger of the two.  Thus the anonymity set is reduced in each group from
that of the original, overall population, with that reduced set size modified
in the relay operator group by a trade-off between relative anonymity and
performance based upon the data relay rates of their servers.
     Let's examine that last statement a bit closer.  Relay operators are
probably a small subset of the overall user population, so distinguishing
one's traffic as being that of a relay operator by getting a higher priority
for the traffic probably vastly decreases one's anonymity from the current
level.  However, the data rates among servers vary widely and are not
uniformly distributed.  Servers with published peak data rates
greater than, for example, 4,000 KB/s are very few in number.  Such a "paid"
system would essentially guarantee that the traffic of operators of those
servers would have a high priority all the time because they would be unlikely
ever to use much of their accumulated credit.  That means those folks could
download huge files, always at a high priority, which might make their traffic
more identifiable as being possibly/probablytheir traffic.  (This kind of
traffic analysis problem is really way out of my area, though, so I feel quite
in the dark as to how useful such distinctions might actually be to an
attacker with great resources at its disposal.)  Would the cost in anonymity
of running a high-data-rate relay encourage some operators to reduce their
servers' data rates artificially to keep their client-side traffic from
originating from such a shrunken anonymity set?  E.g., would blutmagie get
a RelayBandwidthRate of, say, 500 KB/s (i.e., < 10% of its typically published
peak rates) in order to improve the operator's anonymity?
     Meanwhile, the client-only users would get reduced anonymity and poorer
performance, but their anonymity, at least, is not reduced anywhere nearly as
much as that of the relay operators.  So the introduction of such a system
certainly makes the situation much more interesting, but not necessarily in a
way that makes tor's behavior any easier for users, naive or advanced, to
understand.
>
>As for the second question, I think it was:  what prevents relay
>operators from choking off all unpaid traffic, in order to maximize
>profits?  As an answer to that, I'd say that not much prevents them
>from doing that.  Perhaps there are anonymity benefits to allowing
>unpaid traffic as well (since there would be more ambiguity as to the
>original source of the traffic).  There might also be ethical benefits

     As I hope I've shown above, that anonymity benefit would be partly lost.
I don't know offhand whether there would be some remaining incentive to
carry the "unpaid" traffic.  Perhaps the authorities would have to add a
test for that and apply some sort of penalty (e.g., another flag or perhaps
a refusal to distribute the descriptor).

>to allowing unpaid traffic, ie, much the same motivation for the
>current operators of Tor relays.  Finally, if this were the default
>behavior, novice users would be unlikely to change it, and that alone
>might be enough bandwidth for unpaid users.
>
     Frankly, at this point I don't think such a system of "payment" for
relay priority is worth the cost in either development time and effort or
anonymity and prospective user discouragement.  Many of the people in this
world who have the greatest need for the benefits of a system like tor are
also the people least likely to be able to run a relay without fear of
harassment or worse from the states that rule them.
     I started running a relay because I believe it's a good thing for all of
us.  It helps me, IMHO at least, and it helps others at the same time, so
what's to lose?  It's too bad that the Internet wasn't designed with such a
system built into it so that *all* traffic could have been handled in a
fashion similar to what tor does.  But back then, who knew?  We had to crawl
before walking.  So today we have to build on what we have, and maybe we'll
someday get there or somewhere near enough not to matter.
     The tor developers have, I believe, far more urgent matters to deal
with than creating a priority system, and I don't think any priority system
design has yet been shown not to have potential negative effects on the tor
community.  I'm not trying to discourage anyone (except possibly the tor
developers) from trying to dream up such a design, but the development team
should focus first on the things it knows need to be done.  Thus far, it
seems to me that they have been doing an admirable job of that and shouldn't
be diverted from continuing to do that.  They have already found and corrected
quite a few performance problems, and using tor now is usually a much better
experience that it was when I first started using it in 2005.  They have
already identified more such problems to be fixed, so let's see whether the
better performance from those changes will help to reduce the impatience that
drives the requests for a priority system before we worry about adding one to
tor.


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