search

ipfs / specs

Technical specifications for the IPFS protocol stack
https://specs.ipfs.tech
1.16k stars 232 forks source link

IPNS pub key size concerns #256

Open Gozala opened 2 years ago

Gozala commented 2 years ago

Recently I was told ed25519 are preferable for IPNS over other keys due to their smaller size. However it is not in the list of supported algorithms in web platform requiring bundling crypto libraries etc...

This got me thinking about potential ways to address this problem, especially since is safe to assume that over time longer keys may proof necessary.

Idea 1.

Right now public keys are endoded IpnsEntry protobuf (which is presumably where we small size is desired). In practice chances are node receiving a record already has a public key because:

  1. IPFS default is to use self key so it was used in handshake.
  2. Recipient has some interest in a IPNS record so key was previously obtained.

If thees assumptions holds, we could make next version of IpnsEntry encode CID for the public key instead. Furthermore small keys and rare keys could use identity hash CIDs. It is also assumed that Sequence 0 record will use identity hash.

Idea 2.

What if instead of basing mutable namespace on the public key we based it on mutex block (genesis block) CID instead that use designated muticodec code. Mutex blocks could encode multiple public keys allowed to perform updates, and also be fairly open ended to allow new or domain specific metadata to be added e.g.

  1. peer ids of nodes that are likely to have latest record.
  2. DNS alias(es)

I think this would also neatly combine IPFS and IPNS namespaces where /ipfs/$cid represents content on creation and /ipns/$cid represents content now. For /ipns/$cid where cid is not for mutex it would be identical to /ipfs/$cid because it's not a mutex so it could never change.

Additional benefit of such mutexes would be that they could cleanly integrate into IPLD as they are addresses by CID.

hugomrdias commented 2 years ago

idea 2 seems super interesting 🤔

Stebalien commented 2 years ago

The core issue is that DHT servers need to be able to verify IPNS records without making any network requests. IPNS records used to not include the key (just the peer ID).

Also note: it's not just the key. RSA signatures are the same size as RSA keys (i.e., massive).

IMO, the best solution would be to either:

  1. Convince browsers to support ed25519.
  2. Use ECDSA. go-libp2p, at least, supports this out of the box.

Is a stand-alone ed25519 library really that big? I understand lots of js-crypto libraries are, but I assume a stand-alone unbundled algorithm isn't terrible.

hugomrdias commented 2 years ago

we now use https://github.com/paulmillr/noble-ed25519 and its small enough IMO