Don't allow using one RSA keypair for both encryption and signing

[keks]

As Kubuxu pointed out, this is dangerous. Let's not allow it.

[whyrusleeping]

Good note. We've currently (temporarily) dropped the encryption code from the interface, so when we bring that back, we should make sure to have 'modes' on keys to prevent both being used.

[Kubuxu]

This isn't huge risk but it is generally recommended against.
So if it is very difficult it doesn't have to happen but should be warned in the docs.

[keks]

Does anybody know of a standard for signing encryption keys to say if you want to send me encrypted messages, use that one? In OpenPGP these are called subkeys and you attach them to your public keys as explained here. However I'm not convinced we should incorporate PGP-style key representations...I like the approach though.

We could then let a joint key type, that contains both the signing and the encryption keypair, implement both Signer and En/Decrypter. I don't know how the IPFS code base would react to that, though...

[bigs]

re-opening because it will become relevant when we bring back this encryption functionality

[jacobheun]

We'd like to use the encryption support in js-libp2p to help better support distributed signaling servers, like webrtc-star. We leverage webcrypto in browser, but it rightfully doesn't support using the same key as signing. We can pull in some large libraries to get around this, but it would be ideal to avoid doing that and start using separate keys.

[Stebalien]

Update: I've completely dropped support from RSA keys so we could add (optional) support for OpenSSL (which doesn't support this).

[Stebalien]

Fixed.