Re: [tor-dev] high latency hidden services

[Michael Rogers <michael@xxxxxxxxxxxxxxxx>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 09/01/15 14:40, Yawning Angel wrote:
> 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.

Thanks for the pointer to an excellent paper. The single-hop padding
scheme I suggested is closer to CS-BuFLO than BuFLO: it operates over
TCP, doesn't inject padding when the TCP connection is congested, and
allows the initiator to decide when to close each hop of the circuit
(similar to CS-BuFLO's early termination).

> 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).

Why do you need stupid amounts of buffering? Bursts of data from the
application can be smoothed out by keeping a small buffer and making
the application block until there's space in the buffer - as TCP does,
for example.

In general I don't see any need for a padding scheme to touch anything
below the TLS layer, or buffer any more data at the endpoints or
relays than is already buffered.

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

I don't see why padding needs to make multiplexing more complicated.
We already have logic for multiplexing circuits over a TLS connection.
Padding cells don't behave any differently from data cells in terms of
head-of-line blocking.

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

Is it necessary to detect peers that aren't padding correctly? In
adaptive padding, if a relay detects a gap in the incoming traffic
along a circuit, it doesn't try to assign blame for the existence of
the gap - it just fills it. Likewise for the single-hop padding scheme
I suggested: each relay is responsible for normalising its output, not
speculating about why its input was or wasn't normalised.

Cheers,
Michael
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQEcBAEBCAAGBQJUvkW6AAoJEBEET9GfxSfMM0kIAISz9Kg4jKqaAlnui6eHFWz8
X/ApFiwlPHhEGGbb971LdCuY8O+ycz/wPLAL18UO9uMXUYDz5YF9iZyWFRHBlKB1
83qENqhm6WCJUqC00BVk5GjJ4tPEQ/BgwIZyz2ZEq1kfUdnSJoBib25sUPC2uU6r
h8rM2mJXyXj/6BxnVYQB9TKMzPDjCebR32aMOXJjxymy0B4Y3zwtlIiJje/Sz77i
YFdz3FdBQ1yoAyaTny2ww8cn8BQN0rieXZnfvG2Gq9rT8uFe84Z8zR3rz5O1fjgi
86tiX+TZbXImdsOO/sEOqaSO9kCsq37rfV2oslSGcWjxJUwUymInFSkrt52F4AU=
=cKyL
-----END PGP SIGNATURE-----
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev