Hi, I hope it's ok for me to post this here, I need some feedback on a public key infrastructure. In return, you might enjoy reading it.
My goal here is *only* to link public keys to guids, and like spki/sdsi, I assume you already know that the guid as such is bonafide, and I am not trying to link the guid to "Walton's Mountain assumptions" about a real-world person or entity. The only reason I don't use the public key itself directly as the guid, is that I want the guid to be human-memorable (Zooko's triangle); let's say they are email addresses. The problem with using web-of-trust for this is that many times you will want to give someone your email address and start communicating from scratch, without an introducer. Even if a connection exists, it would require search to find it, and search is difficult without centralization. Also my list of "friend-of-a-friend"s (FOAFs), through which i have a chain-of-trust with you, may contain private information about who i hang out with. So the whole web-of-trust approach is a hassle, and also privacy-sensitive. The CA-approach is out of the question from the start, because it's too centralized. So what I came up with was to define a "fabric"-approach. We define a multi-dimensional space in which all guids represent a fixed position. Your coordinates in the fabric are determined not by you, nor by who you interact with, but simply by the ASCII bits in your guid string. And then it's simple: everybody sign the keys of their neighbours and vice versa to form the fabric. Now to know your public key, I just walk from my position in the fabric to yours, following the chain of neighbours that are all 'holding hands', and so everyone's connected with everyone. The idea is that the fabric sums up all the security of everybody, and links it together to make it strong. If you would want to compromise one guid, the neighbourhood watch would notice and refuse to interact with the conflicting public key. If you compromise a whole area, the neighbours of that area would notice. Etcetera. I tried different ways to define the "neighbour" relationship, and in the end I ended up defining a combination of additive and Hamming distance, on bitstrings obtained from the original guid string with non-reversible hashing. I think I sort of got it working, and it seems pretty efficient. But the details of that are not what I wanted to bother you with right now. The non-reversible hashing is there so it's not trivial to 'embush' someone by registering a ring of email addresses around him. It makes it hard to guess a given email address's neighbours, and thus hard to stage an embush. You could still attack the system by flooding it with guids until you are the owner of 99% of the guids. So all guid-providers should put up a captcha to avoid that sort of attack. Also, you would need to define what needs to be done if a tear in the fabric is detected. if there are 2 conflicting public keys being announced, how do you decide what is the right one? you need to make it hard to 'topple the system' into an auto-immune defense against itself. also DDoS and vandalism attacks need some attention. But i think in general, the pki could sort of work. My question is: does my fabric-based approach make any sense? or am i maybe trying to solve a non-existing problem? There must be a flaw somewhere that prevents other people from doing this already, I just don't see it. Many thanks for your time! Kind regards, Michiel de Jong www.unhosted.org/unhosted.html
_______________________________________________ p2p-hackers mailing list p2p-hackers@lists.zooko.com http://lists.zooko.com/mailman/listinfo/p2p-hackers
