Re: [tor-talk] HORNET onion routing design

[str4d <str4d@xxxxxxxxxxx>]

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

Seth David Schoen wrote:
> str4d writes:
> 
>> * 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).
> 
> If the remote peer has to be actively involved in the onion
> routing process, couldn't it detect replays rather than having the
> routers do it? Or is the replay problem a problem of wasting
> network resources rather than fooling the peer into thinking a
> communication was repeated?
> 

In this design, I would say the major problems are wasting network
resources, and forcing router rotation. There is no way to "cancel" a
session other than to let it time out. This means that an attacker can
replay packets as rapidly as they want in order to overwhelm the
participating routers, effectively DoSing the remote peer (as well as
anyone else whose sessions are going through those routers).

The participating routers can't do anything, because they are
stateless and the packets they are processing *are* valid. The remote
peer *can* detect the replays, but they can't tell the participating
routers about it. All that the remote peer can do is drop all packets
from that session, select new participants and switch to a new session
- - which increases the probability of selecting the adversary's
malicious routers. Perhaps the selection process can be constructed to
minimize the danger, but that is outside the scope of HORNET's design.

str4d
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJVstZjAAoJEBO17ljAn7PgbJMQAI+RQLN473wryhAvQia3XCCA
jJrt0qQH+3uarUzuG7JNeIkhThSO7/iCtLLtQpSSCXCXSB0To8xlJ+I3mCyOeGIO
J+uMyA8aBnytYWIQGba2EvEeyK5oHCLo0+cHBdcCE0VAK6J42ZHUqd6xpdspFFbg
QW4CUk/290aYEhdtraLGEvyOFFGvgSUMVkNmdinm/Gs5vFLZIAGN4SXDagFJktx2
4k+/Gh/a9DZ1/4asVmbrzriF6chxHWI039++YP5V9FyLLaC2Cbgt0bIBZrb2lBK3
EIzwuv42rtlX2PJJQxVbK1MZp35HF4qG+qNcydTYNp6m8b1i1W+ErMljluxJYGKI
PWJY7xCr72SDIgsDHh2UMoqAUggEjPo2ZpSSjNHJmyVp4fwIxIgy4jAZGd+K0DFm
B9jSWSd9ZzUd4plh16Ye0pZHDe95BPWfZLj2z3e6YYnDV4TvaWxA/SZHuL+/b1HJ
5iQJM1ThvEjVCT4GcN9hsVSl/bJQckOxuzuPL82xA0Mj1cggLYrpwCdSzUga4Kgf
bcLTD/Q9xQ5W+PK9IDDP+XTPVQuthLSS77gb19VdKi3PlR2O16rSdCTPL2XDVBJW
XmsNzDwX7tO0vK6V3lpCAZ+vwW1zeqleAUl5mSB39rjK5MbpYYqlKCFqalsa/7gf
7glnFEELqupYiDjeAYrt
=EZME
-----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