-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 08/01/15 11:25, Mike Perry wrote:
You might also like the "Adaptive Padding" defense: http://freehaven.net/anonbib/cache/ShWa-Timing06.pdf. It implements pretty much what you describe here. It is one of my current low-resource favorites.
Thanks for the link! I agree that what I proposed is very similar to adaptive padding. The major difference is that with adaptive padding, the padding cells travel to the end of the circuit, whereas with single-hop padding they only travel to the next relay.
There are pros and cons to both approaches. Adaptive padding protects against a malicious relay that manipulates the flow of data along a circuit in order to see whether the flow of data at a colluding downstream relay is affected. With adaptive padding, the first relay downstream from the point of manipulation will inject padding to smooth out the flow, and the colluding downstream relay won't be able to distinguish the injected padding cells from data cells. But this defense doesn't work if the adversary controls the downstream endpoint rather than a downstream relay, as the endpoint can distinguish padding from data.
Single-hop padding doesn't prevent colluding relays from discovering that they belong to the same circuit, but it may provide better protection than adaptive padding against an external adversary, because it makes it possible to have a different start time, end time and traffic rate for each hop of a given circuit. It's also compatible with Tor's existing cell encryption and end-to-end flow control, whereas it's not clear to me that the same's true for adaptive padding.
Marc Juarez actually has a reference implementation of this defense as a pluggable transport: https://bitbucket.org/mjuarezm/obfsproxy-wfpadtools/
It is a generalization of the Adaptive Padding scheme, and is described here: https://gitweb.torproject.org/user/mikeperry/torspec.git/tree/proposals/idea...
Our goal is to study this as a defense for Website Traffic Fingerprinting, but I also believe it has promise for frustrating E2E correlation.
Great! Preventing end-to-end correlation of hidden service traffic is my main goal here.
Unfortunately, hidden services also represent the hardest form of E2E correlation - where the adversary actually gets to control when you connect, and to a large degree what you send (both in terms of amount, and traffic pattern). In this sense, it actually resembles a Global Active Adversary more than a GPA. It may even be harder than a generic GAA, because of the "adversary also decides when you send data" property.
That's a really tough problem, but I think it's also worthwhile to consider the easier problem of preventing E2E correlation when the client and the hidden service are cooperating - for example, a Pond client and server that want unlinkability rather than mutual anonymity.
For that use case we may be able to find a relatively simple, low-overhead solution that doesn't depend on datagram transports, new flow control algorithms, etc.
Cheers, Michael