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

[str4d]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Michael Rogers wrote:
> On 14/11/14 21:23, Nathan of Guardian wrote:
>> Otherwise, I am all about HIGH-latency anonymity systems these 
>> days, so the more we can think about mobile messaging over Tor as
>> a transport for all things, the better!
> 
> I totally agree about the value of high-latency anonymity systems,
> and unsurprisingly I also agree that messaging over Tor is a good
> idea, but I think we should devote some time to working out how the
> two things fit together - maybe try to get the Tor research
> community interested.
> 
> 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)?

> 
> Done right, this could provide a large anonymity set for the 
> high-latency users and improve the traffic analysis resistance of
> Tor for the low-latency users at the same time, by providing a pool
> of latency-insensitive traffic to smooth out the bursty
> low-latency traffic between relays.

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

str4d

[0] http://i2pbote.i2p.rocks/
[1] https://geti2p.net/en/docs/spec/tunnel-message (search "Delay)
[2] https://geti2p.net/en/docs/spec/i2np#struct_DeliveryInstructions

> 
> Cheers, Michael _______________________________________________ 
> Guardian-dev mailing list
> 
> Post: Guardian-dev at lists.mayfirst.org List info:
> https://lists.mayfirst.org/mailman/listinfo/guardian-dev
> 
> To Unsubscribe Send email to:
> Guardian-dev-unsubscribe at lists.mayfirst.org Or visit:
> https://lists.mayfirst.org/mailman/options/guardian-dev/str4d%40i2pmail.org
>
>  You are subscribed as: str4d at i2pmail.org
> 
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJUbk6tAAoJEIA97kkaNHPnZLkP/jY/YECsWZ3IcOgFPbVYl5Jd
U+LJdowQCJJ8ud8kvcxl0Xx5Q7GOOMznJUitxtdjtXmpyX3FhfkWMrB9yKxQTzvS
wXnVIdn5vj7oTTxvI/a5uWJu3EzX3JRj91/CSXI2CNi0ZjlieocHGx3o1jFubROf
jyKoY/kEe6T1cWvvXXmibTfxIL4IamYVsZrowLSs4hg9PXesmJAobl/r+32777hm
rBJgUSbcMvD6c8z9sHIBk8L0Hs+m9z+odYxzAboln6jSbT5kpjC8v+DzX4FhFeM9
pRIveEPji2AhBMWR3nZIH+7KNoqp3eN7D7g9R7IL0HVqkcZCrMl61Odo+K04j8tG
hiPlcWQ05R8Y42N6CMRXi9A7v8lBQGhITHr9swHERSC269Fu3UKfeEMuqU2W+oqS
RW3chf00n0VmzqOuuRuftxiImGJoz5e88xS3zsKCXDqhkOyWSOxF/k640cKVs7tQ
GxN7qoA+P7vAdD8d8eMEq+ghZ0ICwF3rzTEvtrKmhh3qKTOEU3yAUt3q7dxB1caP
NkVHA9f2GeHIVsflU+94R6mNINuAH/bDz+mMwu0s54MVDaA+kbx2TqgTqECS62XN
w4k+SwW5cd14VQHqFJ+zVimbig0kTAUL4P98wecfLxgyHa3FxvFvejCkONOSjbnO
qBqwLBbRL7JUa5O5iT7u
=kqdi
-----END PGP SIGNATURE-----