Re: [tor-talk] HORNET onion routing design

[str4d <str4d@xxxxxxxxxxx>]

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

Jeffrey Burdges wrote:
> I have not but I'm happy to read the article.
> 
> Is there a discussion group for onion router and mixnet design?
> tor-talk might be a big generic for this.

According to https://lists.torproject.org/cgi-bin/mailman/listinfo
tor-talk is for "all discussion about theory, design, and development
of Onion Routing". So I think it is fine here :)

> 
> On Wed, Jul 22, 2015 at 11:36 PM, Seth David Schoen
> <schoen@xxxxxxx> wrote:
> 
>> Has anybody looked at the new HORNET system?
>> 
>> http://arxiv.org/abs/1507.05724v1

I've read it, and it's quite neat. The paper has a few bugs in the
Evaluation section that made its results a bit harder to follow in
places, but I assume these will be caught and fixed in a v2.

>> 
>> It's a new onion routing design that seems to call for
>> participation by clients, servers, and network-layer routers; in
>> exchange it claims extremely good performance and scalability
>> results.

AFAICT, the two primary reasons for this are:

* Stateless data transmission (as they say on the box) - the routing
info is replicated in every data packet, removing the need for local
lookups. This increases the data packet header size (7 hops requires
344 bytes for HORNET, c/f 80 bytes for Tor and 20 bytes for I2P), but
massively reduces memory load (Tor stores at least 376 bytes per
circuit, requiring almost 20GB of memory for a load level of 5 million
new sessions per second).

* No replay detection - packet replay is ignored within the lifetime
of a session. They suggest that adversaries would be deterred by the
risk of being detected by volunteers/organizations/ASs, but the
detection process is going to add additional processing time and
therefore compromise throughput (c/f I2P uses a bloom filter to detect
packet replays, and this is the primary limiting factor on
participating throughput).

>> 
>> I think it also calls for the use of network-layer features that
>> aren't present in today's Internet, so it might be hard to get a
>> practical deployment up and running at the moment.

Only as far as recommending that the routing participants be actual
hardware routers, because this is easily possible with a stateless
protocol. HORNET doesn't specify how a path from source to destination
would be determined, but merely assumes that such a path can be found.
It should therefore be possible to implement a HORNET-based routing
overlay using server-side software instead of network hardware,
similar to Tor and I2P. Such a scheme would however not be as
efficient as one based on deployed network hardware.

str4d

>> 
>> -- Seth Schoen  <schoen@xxxxxxx> Senior Staff Technologist
>> https://www.eff.org/ Electronic Frontier Foundation
>> https://www.eff.org/join 815 Eddy Street, San Francisco, CA
>> 94109       +1 415 436 9333 x107 -- tor-talk mailing list -
>> tor-talk@xxxxxxxxxxxxxxxxxxxx To unsubscribe or change other
>> settings go to 
>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
>> 
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJVsY3jAAoJEBO17ljAn7Pg0cgQAJn60kYrn9oHyWUY5EyewwGL
iq3q+P5xIRc2qto55TlgZgbWk6oIlIxtIQsPaxUYAOEvClHkDOI314QSzKoFG6p+
sELgQN6t3fgLpj/DQNl54DLpIJcHP06Wk+BNr9r0/scf/0S2Im1BAY6m8zdSMF/+
se8dzaCSBa3LzHaweOihtQluBHHeMsoZKkJqzcRcvl4zEByrehK+FjAY2IJUCxqf
gvaVBwEnnut8tWrrAiaxEQcU2EYYga4rPF9HCwkkAE+05VS9NRhXAQ5R8zsO2vEo
Sbxf5z+NpLr/2zc1qIpTGod7PmVmDqZw+3U8j046DA2ekVzyO+wDw51UXhDwPcLH
UgsKXzuQVQWMzTAYMLwW5zozJYSnL75wlnsWlfUgwNk6tI7OCTNrNptgA1a2LxiB
YkXWLZApLJW4bb8S66KcbTfF4yeK+Rp0bCO8XyP1xsKFeIjkd2HyvTT49nsSU9xs
IXRlRCnZH4k5+mlfuTtN4zLwHJ9bjlnG/RB5/I4FhkzvVsk5Ybj6tkIYSYfuIIVk
qF3qb/HLVNw4IZ9aGF6OgDzp5+cYXiHkgCOjTTEy9j8J1Jo7fuRl/1ulJojx4+Ip
FnsxYEZRNp8xM7OeJCOl6DBJBMgCGupKsKddUTYE6423DdQTqQm2vZYqnkymUXkH
3grH/iGkMkNSJ1B5ESkh
=wmQr
-----END PGP SIGNATURE-----
-- 
tor-talk mailing list - tor-talk@xxxxxxxxxxxxxxxxxxxx
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk