> Presenting text for the user to input via an image is one way. The image > can have a lot of noise to make it virtually imposable for OCR software > to recognize without errors. I am sure there are other ways.
But who generates the text? A malicous node could simply not generate any text and 'pretend' they have. Unless, random peer(s) generate parts of the key, and encode them as OCR-proof images which the user must enter. > Although it will be a pain for the user. How about having multiple > (random) nodes verify the data with each of them appending the signature > to the information. Since replying to email is not a lot of trouble you > could require say a dozen nodes send email to the user and verify that the > email address is indeed valid. It would be difficult for all of them to > be cancel nodes. Heck you can even make it larger then that. Replying to > all those emails will be a pain but it will only have to be done once. This would work to ensure that only people that actually have access to an email address can claim a key from it, but it still won't get rid of the man-in-the-middle problem, simply shift it to the mailbox. However, it would certainly up the difficulty of such an attack. > If cancel nodes can be identified some way and one of the nodes > verifying the information is a cancel node the information should be > thrown out. > > Then there is the actual security of the email address is question. But > since the mail will be coming from so many different directions an > attacker would really have to compromise the mail server.... Yes, I think some form of bad node detection should definitely be built into such a system, like my suggestion of keeping 'routing slips' with each message to find common nodes in paths that result in invalid keys. Unfortunately, this destroys anonymity. > > for example, what do you do if you use the network to look up the pubkey of > > someone you want to contact, and it turns up more than one key, at least one > > of which could be the key of an intruder trying to listen to your > > conversation? > > In that case the information should be thrown out. But what if the user has at some time created a second key under the same email? > I think there would have to be some way to make nodes accountable for > there actions and be able to detect the cancel nodes. I believe GNet is > working on such a problem. Certainly. (See my comment above). I'll take a look at gnet :) Nick _______________________________________________ freenet-tech mailing list [EMAIL PROTECTED] http://lists.freenetproject.org/mailman/listinfo/tech
