Go-ipfs swarm key discussion

Private IPFS networks can be created by referencing the Swarm key generated by the ipfs-swarm-key-gen package developed by @Kubuxu (Lots of thanks & high fives!)

I took a glance at the code and the package seems to use crypto’s rand.Read() to assign random values in a byte array initiated as key

However, I’m interested to understand the probability of repetition of the swarm key generated by another arbitrary node. Is it fair to assume this is mathematically implausible?

EDIT 1: Also wondering if a node X could receive 2 swarm keys belonging to respective private swarms A and B; to allow requests to data from disparate swarms without merging the both the networks? Could that be in alignment to IPFS thinking?

All thoughts & comments are welcome.

Is it fair to assume this is mathematically implausible?

Yes.
As you can see from the code, it uses 32bytes of randomness. This gives 256bits of key material.
There are about 1e77 unique keys (1 with 77 zeros).
256bit symmetric cryptography is regarded as state of the art. Most other protocols use the same key lengths.

Also wondering if a node X could receive 2 swarm keys belonging to respective private swarms A and B; to allow requests to data from disparate swarms without merging the both the networks?

It should be possible to write a proxy/bridge like that.

Thanks for the revert! Hope to work with you on the proxy bridge for heterogeneous private networks…
Will take this up on GitHub & revert as I have some plans designed as well.

1 Like

Hi @Kubuxu,
I am following up on an old thread we had a conversation regarding connecting two ipfs swarm clusters.

You had asked me to file the issue in the repo. Please find the link here: https://github.com/Kubuxu/go-ipfs-swarm-key-gen/issues/3

Look forward to your inputs on this. Thanks.

1 Like

I am going to face the same trick… That seems not solved

But it could be possible with 2 IPFS daemons on same Node using different swam.keys and sync with “ipfs1 get + rsync + ipfs2 put” cycle… What do you think about that “heavy” approach? Should work…

Hi @qo-op, yes - that should work.

1 Like