Changes between Version 35 and Version 36 of thesis


Ignore:
Timestamp:
Apr 26, 2011 1:49:25 PM (9 years ago)
Author:
zzz
Comment:

Legend:

Unmodified
Added
Removed
Modified
  • thesis

    v35 v36  
    9494**> http://www.i2p2.i2p/meeting125 (~13:12-13:30)
    9595
     96**> I still don't think you have justified the "bad design decision" phrase so let me try again:
     97
     98**> 1) It's based on an arbitrary certainty vs. time weighting (tradeoff) you have decided that may not be applicable in all cases. For example, Somebody could  make a list of possible IPs then issue subpoenas to each. You could use your botnet to DDoS each in turn and via a simple intersection attack see if the eepsite goes down or is slowed down. So close may be good enough, or time may be more important.
     99
     100**> 2) A full analysis of the tradeoffs of unidirectional vs. bidirectional tunnels is clearly outside the scope of this paper, and has not been done elsewhere.
     101
     102**> 3) Tor uses bidirectional tunnels and has had a lot of academic review. I2P uses unidirectional tunnels and has had very little review. Does the lack of a research paper defending unidirectional tunnels mean that it is a poor design choice? I think it just means that it needs more study. Timing attacks and distributed attacks are difficult to defend against in both I2P and Tor. The design intent (see references above) was that unidirectional tunnels are more resistant to timing attacks. Yours is a somewhat different type of timing attack though. Is your attack, innovative as it is, sufficient to label I2P's tunnel architecture (and thus I2P as a whole) a "bad design", and by implication clearly inferior to Tor, or is it just a design alternative that clearly needs further investigation and analysis? There's lots of other reasons I would consider I2P currently inferior to some other projects (small network size, lack of funding, lack of review) but is unidirectional tunnels really a reason?
     103
     104
    96105   Once the attacker's routers are a large portion of the victim's fast tier (e.g. 'one ping enough'), all sorts of analysis and attacks are possible, and many would be the same or easier with bidirectional tunnels. While we appreciate the innovation of your timing analysis attack with our unidirectional tunnels, the victim is eventually owned via any number of attacks when his fast tier is overtaken.
    97106
    98107< This is all a question of degree: how fast can the adversary be how certain of the identity of the user.  You are right that in general, the attack still applies to bidirectional tunnels as well.[[BR]][[BR]]
    99108
     109**> See above
     110
    100111   Also, given future increases in network size and  implementation of recommendations, the tradeoff of analysis time vs. false-positive rate may change. For example, a 30x increase in analysis time for unidirectional tunnels is not insignificant. What if the fast tier size was increased to 1000? Then the time would be 1000x.
    101112
    102113< Yes, and accuracy would be x1000000.  So while now the adversary might want to observe the victim in the correct position in 100 tunnels for 99.9999% certainty, the same might be achieved with just a single observation once the fast tier grows to 1000 peers (numbers given are random values, not based on specific facts, other than the x1000000).  Also, given that the adversary has "infinite" time (Eepsites are online a long time), the time increase is likely to be not so dramatic, whereas accuracy is something that might in general be harder to improve.[[BR]][[BR]]
     114
     115**> See above
    103116
    104117  Paper's recommendations:
     
    118131
    119132< Okay, we mention is ongoing process as possible solution.[[BR]][[BR]]
     133
     134**> Tahoe-LAFS is of course just one of a number of possible distributed or DHT-style file systems that could be overlaid on the I2P base technology. It's been said that I2P won't really be complete until we have a solution here. Maybe that's true. But certainly we want to make hosting of a service on a single router as robust and anonymous as we can make it.
    120135
    121136   3) Use random peers for leases (guard nodes):
     
    142157
    143158< We tried to avoid suggesting measures that obviously trade performance for security.  I2P is a low-latency design, so adding artifical delays would seem a rather significant change.  If done right, yes, they would likely make the attack harder --- at the expense of making I2P slower; this risks reducing the size of the userbase and hence might do more harm then good in the end.  Tough call.[[BR]][[BR]]
     159
     160**> Right, tough call, was again just thinking out loud here.
    144161
    145162   4) Disallow multiples from the same /16 in the fast tier