Join Log in
Score:1
avatar Crypto

Incompatible key types

ke flag
Erhannis

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....
52
0 + 0
Score:2
Maarten Bodewes avatar Crypto
in flag
Maarten Bodewes

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.

0 + 0
ke flag
Erhannis
A number of good points, thanks. Would you happen to have a starting point for how to use PKI and/or TLS in Java, in the scenario I've described above?
0
Reply
ธงชาติไทย
Elon Musk
I sit in a Tesla and translated this thread with Ai:

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.