On Friday 16 January 2009 21:18, Robert Hailey wrote: > > On Jan 16, 2009, at 2:43 PM, Volodya wrote: > > > Robert Hailey wrote: > >> > >> On Jan 15, 2009, at 4:47 PM, Matthew Toseland wrote: > >>> Why would we want to route the request to a node that isn't optimal > >>> for the > >>> key? And anything that probes for the existence of a key obviously > >>> is bad. > >> > >> Forgive my ignorance, but why is any kind of probing obviously bad? > >> > >> My whole point is that we probe (maybe two or three) peers to find > >> out > >> the optimal path, and pick the one with the least latency for a > >> realtime > >> request. > >> > >> If a node receives such a request, and it has it in it's datastore, > >> the > >> latency is transfer time, otherwise it is the (best) downstream time > >> plus transfer time. In either case you add to the time-claim that > >> time > >> expected to finish other realtime requests queued in front of it. > > > > I think toad_ is talking about privacy considerations here. Somebody > > can use > > this to prove the datastore of a sigle peer. However, i don't > > understand what is > > the different between this and actually requesting the data and > > measuring the > > time yourself for the attacker. If there isn't any difference then > > there is no > > *extra* problem. > > > > - Volodya > > Remarkable... that makes it seem like "slowness=privacy" & > "freenet=slow"... > > But in thinking about it... it actually makes it more secure in that > sense, because the remainder of the request would be 'streamed' > through several nodes as usual, so the best an attacker could > determine by a latencyEstimate()~=linkSpeed() is that the requested > node either has it in it's datastore OR has a bandwidth to peers > higher than yours OR has at least one good peer with a clear low- > latency queue. > > What's more, if a node was sufficiently busy-enough to have an > attacker be able to measure it's latency estimate between datastore > and remote requests, then surely it would also be busy enough to have > multiple lowlatency requests therefore confounding that measurement > (making datastore requests look remote, I might add). > > Or if a node was sufficiently idle for an attacker to be able to "feel > out" requests to various uris, adding a small random latency (average > link to a peer), would both easily confound that and might buy our > node props for getting requests ahead of schedule.
Having to wait for 3 probes to come back is several round-trips. This is bad. Apart from that, the privacy considerations are serious: one classic attack is to request a key, and then kill the node that served you it. It's not viable now because in requesting the key you propagate the content you are trying to censor. Your proposal removes this property.
pgpDsr0Nerh06.pgp
Description: PGP signature
_______________________________________________ Devl mailing list [email protected] http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
