Re: [tor-talk] High-latency hidden services (was: Re: Secure Hidden Service (was: Re: ... Illegal Activity As A Metric ...))

[Gregory Maxwell <gmaxwell@xxxxxxxxx>]

On Sun, Jun 29, 2014 at 5:58 PM, Seth David Schoen <schoen@xxxxxxx> wrote:
> I wonder if there's a way to retrofit high-latency hidden services
> onto Tor -- much as Pond does, but for applications other than Pond's
> messaging application.
[...]
> Then a question is whether users would want to use a service that takes,
> say, several hours to act on or answer their queries (and whether the
> amount of padding data required to thwart end-to-end traffic analysis
> is acceptable).

If such a facility existed, e.g. a "mailbox delivery to a hidden
service" we would use it in Bitcoin, at least optionally for
broadcasting new transactions (We already use hidden services). Many
seconds of delay are basically always acceptable for transaction
broadcasts and privacy conscious users would probably not mind using
hours in a reliable system, at least if they could reduce the time
when they wanted to do so.

Designing this well may be tricky.  To prevent DOS attacks (e.g. I
send you a gigabyte of messages and the network dutifully keeps
delivering them to you) you may want to have the recipient per-approve
incoming traffic... but if if that would allow linking otherwise
independent messages from users it would break some applications.
This is fixable, e.g. connect once to get the recipient to blind-sign
a bunch of return-envelopes with the current HS key... then use them
to authorize delivery, but thats getting into non-trivial
cryptographic design.

Have you seen http://freehaven.net/anonbib/cache/alpha-mixing:pet2006.pdf
 ?  Part of the argument is that having a store of high latency
messages to send through can improve privacy for everyone (e.g. by
padding out links with useful traffic to make passive traffic analysis
harder on the realtime flows).

> One important problem is what counts as "thwarting end-to-end traffic
> analysis".  Right now with Pond, the goal is to prevent anyone from
> knowing which Pond users communicate with which other Pond users and
> when, not necessarily prevent them from knowing who is a Pond user.

Nor does it prevent the pond server operators from learning general
traffic matrix data about their pseudonymous users... e.g. it doesn't
use PIR techniques to check the mailbox.

Bitmessage, which uses flooding (and thus can be seen as the simplest
kind of PIR) could have complete privacy in the receive direction (but
doesn't right now due to braindead protocol design that lets you send
parties messages that they'll automatically respond to), but in the
send direction users are fairly vulnerable to traffic analysis
inherently.

So both pond and bitmessageâ systems which have traffic analysis
resistanceâ would still be improved by this kind of tool.

> Satisfying this property might have implausibly high padding requirements.

If the recipient of messages has a way to rate limit them, he should
be able to choose to not allow traffic levels that would be
conspicuous (e.g. out of line with the level of padding that they/the
network can support).
-- 
tor-talk mailing list - tor-talk@xxxxxxxxxxxxxxxxxxxx
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk