Changes between Version 1 and Version 2 of Ticket #1336, comment 4


Ignore:
Timestamp:
Jul 21, 2014 8:11:44 AM (5 years ago)
Author:
ExtraBattery
Comment:

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #1336, comment 4

    v1 v2  
    11I really think the I2P router should provide this sort of basic protection - at least the hash check at i2cp level as proposed in comment 3. Further measures could be left to applications.
    22
    3 A destination hash is sufficient unless the attacker compromises one of the endpoints, in which case the private destination key was potentially exposed anyway.
     3A destination hash is sufficient unless the attacker compromises one of the endpoints, in which case the private destination key was potentially exposed anyway. [Supplemental: When I wrote this I only thought about the scenario where the attacker is able to capture the decrypted message while it's not in transport, i.e. when it arrives at the receiving end. I'm unable to judge if it's possible to capture a message during transport and successfully (much) later replay it its encrypted form. I see why a timestamp is needed if that is possible. This would theoretically also be true for non-repliable datagrams (or maybe other kinds of messages).]
    44
    55Adding a timestamp sounds meaningful to me. It only has the potential disadvantage that it will prevent routers with a wrong clock from successfully sending datagrams.