js-libp2p icon indicating copy to clipboard operation
js-libp2p copied to clipboard

fix!: remove private key field from peer id

Open achingbrain opened this issue 1 year ago • 2 comments

The only time you'll ever see a private key on a peer id is for the id of the currently running node.

At runtime a service can obtain the unmarhsalled private key by adding a privateKey: PrivateKey field to it's components map so there's no need to have the field on every PeerId.

Fixes #2659

BREAKING CHANGE:

  • The .privateKey field of the PeerId interface has been removed
  • createLibp2p now accepts a privateKey instead of a peerId
  • The keychain operates on PrivateKey instances instead of KeyInfos and PEM encrypted keys

Change checklist

  • [ ] I have performed a self-review of my own code
  • [ ] I have made corresponding changes to the documentation if necessary (this includes comments as well)
  • [ ] I have added tests that prove my fix is effective or that my feature works

achingbrain avatar Aug 13 '24 15:08 achingbrain

Opened as draft so we can agree early on the nomenclature.

  • Things like peerIdFromString return a PeerId which is a Ed public key or RSA key hash or what have you
  • ~~Functions like createEd25519PeerId return a LocalPeerId which is a PeerId with the .privateKey field and are mostly used in tests~~ This is no longer true

I suppose we could change the creation of Peer Ids so you create a keypair, then turn the public key into a PeerId?

achingbrain avatar Aug 13 '24 15:08 achingbrain

I suppose we could change the creation of Peer Ids so you create a keypair, then turn the public key into a PeerId?

I think that's what you and @wemeetagain agreed to on the maintainers' call.

Is there prior art in go-libp2p or rust-libp2p on how they generate peer IDs? Do we have a need to accept the full keypair, so we're validating the person providing that public key so we get out of any impersonation attempts, or noise, with duplicate peerIds on the network?

SgtPooki avatar Aug 13 '24 18:08 SgtPooki

Is there prior art in go-libp2p or rust-libp2p on how they generate peer IDs? Do we have a need to accept the full keypair, so we're validating the person providing that public key so we get out of any impersonation attempts, or noise, with duplicate peerIds on the network?

We don't need the keypair to create a PeerId, just the public key (for Ed and secp keys) or the hash of the public key (for RSA keys).

We validate the remote peer has the private key corresponding to the public key during the connection upgrade process.

Duplicate PeerId being used by different hosts would cause a problem but fixing that is outside the scope of this PR.

achingbrain avatar Aug 31 '24 05:08 achingbrain