The IPFS network uses PKI-based identity. An "ipfs node" is a program that can find, publish, and replicate merkledag objects. Its identity is defined by a private key. Specifically:
privateKey, publicKey := keygen()
nodeID := multihash(publicKey)
So is this āPKI-based identityā a self-signed certificate using the RSA keypair? How is that 2048-bit RSA keypair generated? Is there some default/automated passphrase or some such used? Forgive me if itās obvious, but Iād really appreciate a thorough explanation.
From @hsanjuan on Thu Mar 16 2017 11:34:11 GMT+0000 (UTC)
IPFS generates a regular RSA key pair.
The Peer ID is the hash of the public key. When peers connect to each other they exchange public keys. The communications are encrypted using those keys. You can check that the peer ID matches the hash of the public key provided by a peer to ensure you are talking to the right person.
IPFS stores the [private] RSA key in the configuration. No passphrase. There is no self-signed certificate involved in the whole process.
From @glowkeeper on Thu Mar 16 2017 15:41:47 GMT+0000 (UTC)
@hsanjuan, earlier you said: āYou can check that the peer ID matches the hash of the public key provided by a peer to ensure you are talking to the right person.ā That checking is where Iād imagine a signature or some such like would come into play, but there is no signature. So how does that process work?
Forgive me for blathering on. And feel free to tell me: āgo look for yourself!ā and point me in the direction of the source
From @hsanjuan on Thu Mar 16 2017 15:58:03 GMT+0000 (UTC)
@glowkeeper you donāt need a signature because your name (peer ID) is the hash of your public key. If a node tried to use someone else identify it would not be able to provide a public key which had the same hash as the original to match the ID that it is trying to use. (I mean, it would be able to provide the original public key from the true peer, but it would not have the private key so it couldnāt decode any of the data sent to it).
Other than that there is no trust-schemes or authorities like say, with web certificates.
@flyingzumwalt that is the crux of it right there which I think should be stated more directly somewhereā¦ even though you could imitate a node if you have its public key, you couldnāt decrypt any traffic so it would be useless.
With that said, isnāt this still exploitable in some way? Could you spawn a bunch of false nodes as a sort of ddos attach on a node, thus making it difficult for the system to find the correct node? Even if you couldnāt read the traffic.
The first thing a node does is to contact a different node (boostrappers). If you donāt have the private key, you cannot even start talking to anyone. The lack of signing of DHT records would allow to do misdirect nodes to the wrong peer though, but this will arrive soon I hope (if it hasnāt already).
the problem here is how to distinguish a real IPFS node and a non-IPFS node who just run the RSA key-gen algorithm?
From the source code, each peer is identified by network connection. How can one authenticate the binding between a RSA public key and a network connection?
When a connection happens, the channel is first upgraded and encrypted. This involves exchanging public keys (if needed). If the other node does not have the right key communication will not work.
