crypto.PrivKey in go-libp2p-crypto

Users and Developers
1

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.

2

@iulianpascalau – welcome to the party! :tada:

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

3

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

1 Like
4

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.

5

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).

6

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.