[guardian-dev] 81% of Tor users can be de-anonymised by analysing router information, research indicates

Michael Rogers michael at briarproject.org
Fri Nov 21 09:37:46 EST 2014


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

On 20/11/14 20:28, str4d wrote:
>> If we simply use Tor as a low-latency transport for asynchronous
>>  messaging then we're limited to Tor's threat model, i.e. we
>> can't prevent traffic confirmation attacks. If we revive one of
>> the remailers or build a new system then we're limited to a
>> small number of users, i.e. a small anonymity set. So ideally
>> we'd find some way of adding high-latency mix-like features to
>> Tor.
> 
> I2P-Bote (high-latency distributed encrypted email) [0] falls into
> the "new system" category (even though it has existed for 5 years).
> But I am intrigued by this thought. I2P-Bote was designed to use
> I2P to hide the fact that someone was using I2P-Bote (up to the
> limit of traffic confirmation), but it also includes its own
> high-latency relaying system for sending mail. Are you suggesting
> that its efficacy is reduced by it running over I2P (compared to
> not running over an anonymizing network at all)?

I'm not suggesting that running over Tor or I2P would make any system
*less* effective. What I'm saying is that if we assume an adversary
who can break Tor or I2P's anonymity through traffic confirmation,
then we either need to make Tor or I2P stronger, or build a separate
system that's stronger on its own. If we build a separate system then
it won't provide a large anonymity set until it becomes popular, so we
could face a chicken-and-egg problem.

By the way, I've been meaning to ask you about I2P-Bote's architecture
for a while; maybe this is a good opportunity. Is the DHT where the
messages are stored specific to I2P-Bote, or is it part of I2P?

> The I2P tunnel specification has included support for high-latency 
> tunnels since it was designed. None of it is implemented yet
> because no one had a use for it, but the underlying tunnel protocol
> has defined message bits for supporting user-defined delays both
> along a tunnel [1] and at the end of it [2].
> 
> If high-latency tunnels would actually be useful, we can implement 
> them and get most of the network supporting delays relatively
> quickly (we usually have 80% of the network on the latest release
> within six weeks).

Wow, that would be amazing!

I had a conversation with Eleanor Saitta this morning about creating a
new type of Tor cell with a user-defined delay, and she pointed out
that it would increase the amount of traffic "in flight" across the
Tor network at any moment, so relays would need more memory to support
the same throughput. I guess the same applies to I2P.

The longer the delays, the bigger the storage requirements. At some
point you have to think about writing the data to disk until it's time
to forward it. I imagine that would be a big architectural change, but
I've never looked at the I2P code - what do you reckon?

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

iQEcBAEBCAAGBQJUb046AAoJEBEET9GfxSfM/N0IAKvfImF8vhQ34uGC4i7F6EBL
mdKepGNYiLnJLDqPTJ3n6/xVTdBM0YGXqI7crB4ktvBUGRPGvq2GlCKcX/12TFKe
QkHxoKRB3oqDvEKXgVC64SrHNm5u87FzMsszjWAjhSoIXQ/nJxXaRFkkWIWl3JJM
wgS5n9jYYUA+2TM8PpIoP4HfnImc+xONhdOUsltH3W00tVvJMrg+k8oN7TRjMF33
LJ2Z56mvV/9bD4pUrefOEYBpisIlvCbDhZQrinqo7DMVb0D044XIy+DUCHeWOMhU
Be2mkPM56V1VEjIF5l78NKiLbmDvR3Lw9r7bkYq+u+tAKG5HmNkbKXluuYHSM74=
=5Mwk
-----END PGP SIGNATURE-----


More information about the Guardian-dev mailing list