Right, so i started thinking I’m doing too many trips, because the client and server could just sign their packages. But that doesn’t actually prove anything. After all, someone could have just connected to a server, received their package and then used it to respond to someone connecting to them. That way they’d be pretending to be the other server. The package would be validly signed but not prove the servers identity. Basically we do still need the random phrase challenges from both sides

This does bring up the whole Man-In-The-Middle problem. I could still simply become a proxy between two peers. Not wanting any central service for registering, I’ll probably just go with adding the IP in both the client and server packets. That way we can check that the message originates from the same IP we’re talking to.

Experimented with System.Security.Cryptography.RSACryptoServiceProvider last night to see if i could use it for Public Key encryption between .NET and Mono. Worked flawlessly.

This goes back to my networking thread. I’m currently contemplating using PKI to establish trust relationships between peers. For the sake of this discussion, there is a serving peer, the one that is connected to, hereafter the server, and a client peer, the one that makes the connection, hereafter the client.

Each peer keeps the public keys of its trusted peers. When a client connects it sends its own public key to identify itself. The server first checks whether it trusts that public key at all, then, having passed that test, encrypts a packed containing a random string, plus its own public key with the client’s public key. Only the true owner of the public key can decipher the message.

Now it’s the client’s turn to check whether it in turn trusts the servers public key. If it trusts the public key, the client encrypts a new packet containing the original random string, plus one of its own divising with the server’s public key and sends this back. Again, only the true owner of the public key can decipher the response to its own challenge.

Decrypting the package the server can now verify that the client is truly the owner of the public key, and finally it sends the client’s random string back encrypted with the client’s public key as acknowledgment of its trust and affirming its own identity to the client.

At this point the client should send all the public keys it trusts to the server and the server responds with the subset it trusts as well . Now we have a relationship that allows the peers to trust each other and know what information they may pass on directly, given the others level of trust and what information it would have to proxy, being the trusted intermediary.

I don’t know if I’m re-inventing something obvious here. It seems fairly similar to the SSL handshake, except that I don’t care about encrypted communication, and therefore don’t use SSL. I just want to establish trust on connect.