Incompatible key types

Question

Consider the following. I have a decentralized network of nodes that can talk to each other, and I'd like to encrypt their communications. I turn to asymmetric encryption, the way most of the internet works, and since I've used Google Tink and have some handy code already written out for it, I go for Hybrid Encryption in Tink.

The page on Hybrid Encryption says, "Hybrid Encryption only provides privacy, not authenticity. It is only secure if the recipient can accept anonymous messages or rely on other mechanisms to authenticate the sender." So I figure, well, ok; I'll give each node a private/public key pair, use Hybrid Encryption to encrypt a message with the recipient's public key, and use Digital Signature to sign the message with the sender's private key.

Except, once I set up some code and started testing it, I quickly realized that the different mechanisms support entirely disjoint sets of key types.

Questions:

1. Is this a fundamental property of the cryptographic mechanisms involved?
2. Is there really no way to use the same keypair for signing as well as encrypting, or perhaps even between any two of the symmetric mechanisms given here, either?
3. Do I just have to keep track of multiple keys per node? I had entertained hopes of identifying nodes by their public key; it seemed a particularly elegant solution....

Answer 1

So I figure, well, ok; I'll give each node a private/public key pair, use Hybrid Encryption to encrypt a message with the recipient's public key, and use Digital Signature to sign the message with the sender's private key.

Beware that this is encrypt-then-sign. It is only OK if you only trust the a particular set of participants, and you trust the participants not to replace the signature of any other participant.

1. Is this a fundamental property of the cryptographic mechanisms involved?

No, it isn't. And they forgot to show the hybrid encryption using RSA.

2. Is there really no way to use the same keypair for signing as well as encrypting, or perhaps even between any two of the symmetric mechanisms given here, either?

Yes, you can use RSA for both and ECDH key pairs are generally compatible with ECDSA as well. However, this API is for secure use of cryptography, and using the same key for both signature generation and decryption is not seen as best practice.

3. Do I just have to keep track of multiple keys per node? I had entertained hopes of identifying nodes by their public key; it seemed a particularly elegant solution....

It isn't. Usually you need to have key management. Keys usually have a specified time frame where they are valid. For instance, certificates have notBefore and notAfter fields that do not just indicate when the certificate is valid, but also how long the private (and usually public key) can be used.

It seems that this library is a helper library for developers. It doesn't really specify any protocol. To be honest, I think that these kind of "wrapper libraries" that do not implement and/or are not application specific are of limited use.

I'd strongly recommend that you use two key pairs, one for encryption and signing. To create a trust framework you could use PKI. Finally, it seems you require transport security; in that case I'd recommend TLS.