OK, I understand your system as planned will include all of these pieces but it is a lot to take on. I am going to describe it in the context of some existing projects that have taken on chunks of the problem, for more research areas you may want to look into...
Good question; I'd imagine the p2p nodes are basically super nodes and clients only relay small bits of data .
If the client trusts the source of the private key, it doesn’t matter how the data is sent or received as. (Example, if I trade keys face-to-face it won't matter how the data gets there or received). The issue is that people from china can't all practically swap keys face-to-face, and not everyone is a "Crypto-wizard" to know how to evade "Man in the middle attacks during key exchange over an electronic interface". This is when the "P2P node trust" system comes in to play, basically two people exchange keys on the non p2p network (perhaps a facebook message or IRC). Once to people have their public keys they now can ask the p2p nodes to validate the key by asking for and validating various information transparently for the user.
So there would be a component that would operate like a
PGP/GPG keyserver, but with additional validation over other channels like what the
the CACert Web of Trust CA is doing.
Why do i think this is awsome?
As of right now for a "layman" to accomplish this they have to be educated that they need more than one channel of communication to prove that there was not a man in the middle attack during the trading of public keys, so this solution makes the whole experience transparent becuase unless you meet face to face for publickey exchange your most likely going to exchange public keys through gmail, hotmail, IRC or facebook and unless a "layman" is educated to "resend the same key on a different email address or chat channel and "match the public key letter by letter", then they are vulnerable to man in the middle attacks".
Very true, you just have to make sure the validation process has air-tight security - for example, if someone posted a public key for Josh on
this site (with some cleanup to make it look legitimate of course) is that enough trust? Obviously not. Systems like CACert require a face-to-face meeting with trusted community assurers and checks of government ID to finish the signing process for the Web of Trust cert. It depends on what level of trust you want to place in the system.
Other notes....
New clients can build trust by helping relay small chunks of data;
the actual trust is gained by other nodes if your data seems to match up with nodes that those recieving nodes trust, the more your information matches the more your trusted over time, however if your client is relaying 100% or even 20% false data all nodes are advised to deny data from that client or node (A better solution would be to lower the priority of processing from your node as an attack could be happening and "triggered block occurred")
This would be difficult to protect against, what's to stop me from feeding a node bad data continuously with a coordinated attack from multiple new accounts, slowly increasing the percentage of bad data it relays to take it offline? How does the node itself verify the trust of the original party when it is deciding whether to pass the data along? Also, how do you know you are talking the real person's identity, and not someone that has created an account claiming to be that person?
This p2p crypt app could also provides other opportunities
*Like perhaps even be the leader of SSL certificate authority systems in the far off future: I ponder that if everyone online has everyone else’s key who is currently online along with a rating of "trust" that node is then perhaps we won't need to have CA's at all because there is no more risk of man in the middle attacks (which is why there is CAs certificate list is in browsers).
Yes, once the trust system is in place, it could be used for many awesome things.
*SSL and non SSL enabled websites could rely on the p2p crypt trusted web to initiate a secure login session, cookies and other methods to turn HTTP into a "State full" protocol literally is 2+ decade old technology and computers getting faster while captcha methods failing; The sessions are under constant attack and its time to move on.
HTTP could be used to serve webpages while P2P crypt could allow websites to initiate a "secure session" regardless of an SSL connection. this could allow safe login sessions that are harder to attack on.
This I have to object to, SSL works well, is extensively tested, and highly trusted. HTTP can be stateful without any encryption at all. User authentication/captchas is a separate issue, and in that area it is true that the web of trust would provide an additional authentication option (possibly taking the place of SSL client side certificates.)
Also, how does your system compare to something like
Retroshare?
I know the end goal you want to get to for the trust side, since having a working system of decentralized trust is a 'holy grail' for online systems, and a lot of research has been done in this area as it contains a lot of hard CS problems. The wiki article on
Web of trust is a good resource, and there are many papers (search for 'trust management problem' or 'decentralized identity'.)
Even just a face-to-face-public-key-sharing (or via Bitcoin public keys...) crypto app would be very useful in its own right, however. In any case, I am looking forward to seeing where you take the project!
