the nodeId is a cryptographic hash of the public key and the public/private key pair are generated using Elliptic P256 algorithm. But how this process guarantees the nodeId or the key pair will never repeat among thousands of nodes?
There is no gaurantee, other than the fact that IPFS is using public/private key cryptography, and unless there is a known hash-collission the odds of generating a key thats the same as another node is infinitely small. The great thing with IPFS too, is that it allows for hash algorithm selection to be updated.
For an example, there’s 35 million unique addresses so far on ethereum, so while you could definitely brute-force the keyspace and try to generate the same keypair as another node, unlike ethereum addresses which are holding actually financial value, there is basically no incentive to even do that with IPFS keys as simply generating the same key as another node doesn’t get someone access to abunch of coins hosted at that address.
1 Like
There would definitivly be more incentive if that peerID happens to be the IPNS Private Key of a well-known IPNS address as it would allow the attacker to replace the hash the address points to, but currently DNSLINK is preferred over IPNS due to it’s slowness and such a IPNS attack would also be easily mitigated as the original publisher could simply publish a “newer” hash (which actually is just the original hash) to “revert” the attack. Additionally nodes cache IPNS entries as well so such a well-known IPNS address would likely still be cached on a huge number of nodes, making attacks harder.
But as you said, basically no incentive currently as all attacks would be hard to pull off with little to gain.
So IPFS doesn’t consider the IP address or MAC address of the client, correct?
It is infinitely small that you would get a key that you want by chance, but getting any two keys by chance the same is a few orders higher in possibility, but still super small.
It’s the basis of the so called birthday problem.
So instead of the probability being 1/2^256 = 8e-78, it’s bigger, in range (super optimistical number of nodes) of 1e-65, but still super small.
MAC addresses don’t go beyond your layer 2 broadcasting domain, so no. As for IP addresses they are only concerned as a method of connecting to a peerid…
See https://en.wikipedia.org/wiki/OSI_model and https://en.wikipedia.org/wiki/Broadcast_domain.
I meant using MAC and IP in the key generation process. like the keys are random and don’t depend on any peer-specific factors.
IP … what about NAT?
Mac spoofing, …
SHA256 of a public key from a public/private key is far more secure.
As sebaseba, that seems like a very poor method of generating keys. You want to be able to randomly generate the keys, having predictable values like that being fed into the seed for generating your keys is extremely bad