From @glowkeeper on Thu Mar 16 2017 11:29:16 GMT+0000 (UTC)
I’m trying to understand how identities work in IPFS. This question is related to https://github.com/ipfs/faq/issues/236
Anyway; I run this to initialise an IPFs repository:
initializing ipfs node at /Users/auser/.ipfs
generating 2048-bit RSA keypair...done
peer identity: Qmcpo2iLBikrdf1d6QU6vXuNb6P7hwrbNPW9kLAH8eG67z
The IPFS architecture specs (https://github.com/ipfs/specs/tree/master/architecture), state this:
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.
Copied from original issue: https://github.com/ipfs/faq/issues/238
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 12:20:23 GMT+0000 (UTC)
@hsanjuan thanks! Where is that [private] RSA key stored?
From @glowkeeper on Thu Mar 16 2017 12:39:46 GMT+0000 (UTC)
And how does the RSA key generation work, exactly? Does it just pick a modulus and exponent at random?
From @hsanjuan on Thu Mar 16 2017 13:01:20 GMT+0000 (UTC)
@glowkeeper stored in
~/.ipfs/config by default.
It uses https://golang.org/pkg/crypto/rsa/#GenerateKey
with a random source seeded with current time nanoseconds. (https://godoc.org/github.com/libp2p/go-libp2p-crypto)
From @Kubuxu on Thu Mar 16 2017 13:47:52 GMT+0000 (UTC)
> with a random source seeded with current time nanoseconds.
That is not true, it uses Golang’s
crypto/rand module that uses entropy sources provided by system.
From @hsanjuan on Thu Mar 16 2017 14:24:26 GMT+0000 (UTC)
@Kubuxu thanks, I should have checked before speaking
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.