-----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 > <sch...@eff.org> 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 <sch...@eff.org> 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@lists.torproject.org 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@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk