[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [tor-talk] HORNET onion routing design

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.


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

tor-talk mailing list - tor-talk@xxxxxxxxxxxxxxxxxxxx
To unsubscribe or change other settings go to