[tor-dev] high latency hidden services

[Yawning Angel]

On Thu, 8 Jan 2015 03:25:52 -0800
Mike Perry <mikeperry at torproject.org> wrote:

> I am unfortunately not optimistic about simple low-overhead padding
> being successful here. At the very least, this problem will require
> something more like a congestion-sensitive "always pad if there is
> spare capacity available to grow the CWIND, but no data". We have an
> approximation of this defense, too, in the form of the "Basket"
> pluggable transport:
> https://lists.torproject.org/pipermail/tor-dev/2014-December/007977.html

I believe most of BuFLO's shortcomings documented in Cai, X.,
Nithyanand, R., Johnson R., "New Approaches to Website
Fingerprinting Defenses" 5.A. apply to the currently proposed defense,
though some of the problems have been solved via CS-BuFLO/Basket.

CS-BuFLO as implemented in Basket without application assistance (to
terminate padding early) has an absolutely gargantuan amount of
bandwidth overhead, and the smarter Basket variant that doesn't have
stupid amounts of sender side buffering isn't portable (for the same
reasons that the new KIST code isn't).

> If the adversary is *also* capable of Guard node coercion/compromise,
> then we also want something like "Basket" to pad all the way to the
> middle node, but to accomplish that, we actually need fair end-to-end
> flow control for clients (and by extension, a datagram/UDP transport).

Indeed.  This is something I'd consider fun, but is really hard to do
correctly, since the CS part ideally should be global across all
connections (Basket gets that for free since there's only one TCP
connection per guard, and only one guard).

> (Though also note: We should not need such end-to-end flow control to
> use Adaptive Padding all the way to the middle node, because we can
> approximate fairness using statistics and consensus load balancing
> information).

None of the schemes I've seen proposed so far fit well into Tor as it
is now, due to the fact that multiple circuits are multiplexed over a
single channel (that enforces in-order-reliable delivery semantics).
HOL blocking is a thing that needs to be considered.  Solving this
undoubtedly has really interesting anonymity impacts that I haven't
given much thought to.

Another issue with all of the padding schemes that I currently don't
have a solid suggestion for is how to actually detect malicious peers
that don't pad/pad incorrectly.

I know Marc Juarez is going to be systematically evaluating defenses as
part of his research work, so perhaps he can provide more insight into
algorithm selection.

Regards,

-- 
Yawning Angel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20150109/18978434/attachment.sig>