Re: [tor-dev] high latency hidden services

[Michael Rogers <michael@xxxxxxxxxxxxxxxx>]

-----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/ideas/xxx-multihop-padding-primitives.txt?h=multihop-padding-primitives
>
>  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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQEcBAEBCAAGBQJUvj9eAAoJEBEET9GfxSfMf3QH/0AKebK2Qq9pjkG5vO7bEc/t
PuY8re7fMl/4yCiuWSkePF1sirz55dT08lvv/XrjEK09ly5BH95QZBpe8DNRMBnR
M0DRwyRZmTzoYH0+RfnCp308+XtJvLxivvRxTAPot8XuBnkr+b6xjensZNYeJ6pI
UZIItCXSo/ufKWlpdIFRxU1cnpoo2LLRxJyEwFkIayxvo48HPV+Wa++jZIZ+8A+K
9LGF8c0LNjJ0TO/zYLMJQBGrLC3lHsVhLKrteXNgJOOaTbMjj87+Q6ljEUv15mq3
Qp3A5Qk/dDUdWjHOpeX+bnEM4AX/ZVQW+aLxQzXcG/ahZ/uQR9T7ysoRIQT/p0M=
=I/Ps
-----END PGP SIGNATURE-----
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev