crypto.PrivKey in go-libp2p-crypto

I have a question:

Why does PrivKey intf. extends Key intf.?

If using a custom PrivKey impl, libp2p libraries would know about its raw bytes which, in case of a tampered libp2p source code, might easily be leaked.

I know that PrivKeys rely on Key functionality for storing/retrieving to/from peerstore and that a mechanism for Equal is still needed, but I think these can be modified as to not store private keys as raw bytes (instead it can be stored directly as crypto.PrivKey) and for Equal, each might provide a sort of identifier mechanism (maybe a Sha256 applied over the raw bytes of the private key).

The reason for this question being asked is that, for a protocol that uses libp2p as p2p network stack and the presence of a higher level functionality (that signs/verify data), we might end up using 2 different sets of private/public keys.

libp2p encourage changing in a frequently manner the private/public key used by libp2p stack but this only over complicates the higher protocol by always having to map a particular peer.ID to its corresponding higher level public key.

@iulianpascalau – welcome to the party! :tada:

@stebalien – any chance you can take a steb at this question?

Glad to be here! Nice forum you built! :100:

1 Like

I don’t think concealing the key behind a stdlib type would make any difference. Even if things aren’t exposed via a public API, reflection can give you access to them. I don’t think your concern is any different to running any piece of untrusted code, in any context.

So, if we did restrict the PrivKey interface to just PubKey and Sign, we could leave the private keys in a separate process and make Sign an RPC. This would allow us to use things like, e.g., yubikey’s.

This has come up a few times where we have go-ipfs users who’d like to keep their IPNS keys outside of go-ipfs for security reasons.

(unfortunately, changing this will be annoying).

Ok, thanks for the replies. So, for now, we will keep both pairs of private/public keys (one for libp2p and the other for our protocol) and we will evaluate later the possibility of merging the two pairs.