js-libp2p
js-libp2p copied to clipboard
fix!: remove private key field from peer id
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
.privateKeyfield of thePeerIdinterface has been removed createLibp2pnow accepts aprivateKeyinstead of apeerId- The keychain operates on
PrivateKeyinstances instead ofKeyInfos 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
Opened as draft so we can agree early on the nomenclature.
- Things like
peerIdFromStringreturn aPeerIdwhich is a Ed public key or RSA key hash or what have you - ~~Functions like
createEd25519PeerIdreturn aLocalPeerIdwhich is aPeerIdwith the.privateKeyfield 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?
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?
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.