On Sat, 20 Apr 2002, Nick Johnson wrote: > > I am interested in a similar thing. I would like to have a system which > > will allow public keys to verified against several different criteria. > > > > 1) That a public key was verified by an actual human an not just created > > automatically. By this I mean that after a public key is generated an > > actual human went though a fairly involved process to verify it. This > will > > involve a variety of tasks which will be very difficult for a computer to > > automate. Once the human complete the process the verifier(s) will sign > > the public key. The primary motivation behind this is to allow anyone to > > post messages to a group but prevent spam by disallow certain public keys > > of known spammers. This type of list will be community maintained by some > > sort of voting system. The voters must also have verified keys and may > > vote on other voters to prevent abusive voters. > > Though I can see the usefulness of such a system in building trust etc in > online communities, I can't (off the top of my head) think of any way you > can require some form of manual verification - if the function can be > performed by humans, it's going to be difficult to check the validity of it > by computer, and difficult to require it for a key.
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. > > > 2) Being able to securely attach email address and other forms of > > out-of-band identification information to a public key. Obviously the > > reason for doing this is to make a anonymous public-key not so anonymous. > > This should be easier to do since the only real challenge is doing so > where > > no one particular node can be trusted. Maintaining anonymity in this case > > is obviously not important. > > This would be an integral part of the network I was envisaging. The > particular structure best suited to trusted key-exchange may not acutally > require anonymity, in fact in some cases it might be better without it - for > example, tracking down a node that is 'poisoning' the net by looking for the > common node in all paths that result in 'poisoned' data. > > Another problem that arises is that although a network such as I was > suggesting can ensure data entered at one end can be stored & transmitted > throughout the network with a low probability of modification (and a > statistic that indicates the chance of that) and a high probability of > discovery if a subset of nodes are modifying, Can't the node(s) that verified the data simply sign the information. > there is no way the network > can determine the validity of the data that was entered in the first place 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. 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.... > 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. 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. --- http://kevin.atkinson.dhs.org _______________________________________________ freenet-tech mailing list [EMAIL PROTECTED] http://lists.freenetproject.org/mailman/listinfo/tech
