-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Matthew Toseland wrote: >>> You ask another node to fetch the data. Is that a problem? >> It depends on the probability of your request passing through the same >> node that faked the insert, which can just return the data as if it had >> inserted it. Random audits *might* work, but as usual I'd like to see >> some simulations first. ;-) > > So you have a flag to have it ignore the first few hops or something?
Sorry, I don't follow. Who's performing the audit, the original inserter or another node along the path? Since the objective of the audit is to discover whether your downstream peer forwarded the insert, I guess it makes sense for every node to audit its downstream peer with equal probability. The auditor can make sure the first hop is not the auditee, so the only problem is making sure the audit request doesn't pass through the auditee later on (clustering makes it quite likely that if X is your best downstream peer, X is also the best downstream peer of each of your other peers). I suppose we could just write the auditee's current location in the audit request and say "avoid this node", or maybe route the audit request randomly for a few hops (eg each hop has a 1/3 chance of switching from random to greedy routing)? Another problem is that if there are several audit requests for the same insert, an attacker may be able to learn something about where the insert came from (eg how many hops it's travelled). The probability of auditing each request needs to be low enough to make this unlikely, but high enough to distinguish between honest and dishonest (even occasionally dishonest) peers. I think it's a promising approach though, and it seems like it could also be applied to DHTs. Cheers, Michael -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQFEs+Csyua14OQlJ3sRAkN0AJ4psjkbKFERFtB5MUtEqovvnntNBQCgmne2 VyaA6NrV/E0wDE7yKMQUUSc= =lLLz -----END PGP SIGNATURE-----
