On Mon, May 14, 2012 at 11:57 PM, Michael Rogers <mich...@briarproject.org>wrote:
> It doesn't seem like that would be very difficult. If there's some > proof-of-work step that makes it hard to generate an ID, that step has > to be easy enough for an ordinary user's device to perform when the > user first install the app. Let's say the proof-of-work takes a minute > of CPU time - then an attacker with the same hardware as an ordinary > user can generate 1440 IDs per day, displacing 1440 peers from the > buckets for some random DHT keys. If the attacker's only interested in > one key, 1440 random IDs might not be very useful, but if the DHT is > full of content the attacker's interested in, all those node IDs can > be kept around until they come in useful. > I think tying them to public keys provides the properties you want from a "proof of work" system while still making the keys (particularly if they're ECDSA keys) easy to generate. I don't know if tying node IDs to public key cryptography has negative effects on the statistical distribution of node IDs, but I think it makes a lot of sense for every node ID to have a corresponding private key, such that to obtain a node ID you must first generate an asymmetric key pair, then derive your node ID from the public key fingerprint. I am actually quite surprised to learn this isn't how DHT systems work today. It's what I've been planning all along for my project. -- Tony Arcieri
_______________________________________________ p2p-hackers mailing list p2p-hackers@lists.zooko.com http://lists.zooko.com/mailman/listinfo/p2p-hackers
