For the consumer of the API to send and receive, encrypt and decrypt into that same API, wouldn't the client consumer also have to have the same public and private key as the server that provides the API?

Let's say the private key for the API is on server 1 at our company site 1.

And the same private key for the client is on server 2 at our company site 2.

Is it OK to share as the private key is shared within the company? Normally with this type of encryption, I thought you wouldn't ever share private keys...between the two servers? Now let's say the client is at server 3 at an external company site 3, in that case...would you create both a public key and private key, save the private key at external company site 3 and share the public key between the server-side API and client? The server api code and client code can be trusted but the client and API server are running on different machines.

Code would be this, also saving the data in the JKS file.

Note the public and private keys could be at separate locations. But could possibly be shared.

  • I have removed the part related to programming, because it was not important for this question and made it harder to understand.
    – mentallurg
    Feb 14, 2023 at 14:31
  • Ok, thanks for cleaning up Feb 14, 2023 at 15:17

1 Answer 1


There are many aspects in your question.

1. Keys used for encryption

When A sends message to B, A uses public key of B to encrypt the message. B uses private key of B to decrypt it.

When B sends message to A, B uses public key of A to encrypt the message. A uses private key of A to decrypt it.

2. Hybrid encryption instead of asymmetric encryption

In reality you cannot encrypt big messages with asymmetric encryption. That's why hybrid encryption is used. You generate a random key for symmetric encryption like AES, ChaCha20 or ThreeFish. Encrypt the message using this symmetric algorithm. The encrypt the key with the public key of the receiver.

But also for the hybrid encryption the principle above remains the same: The sender uses the public key of receiver to encrypt the message. The receiver uses its private key to decrypt.

3. Use TLS instead of self made encryption

If you want to use asymmetric or hybrid encryption, the sender needs to know that the public key really belongs to the receiver. TLS uses certificates for this. How will you do that?

If private key was compromised, in TLS/PKI the receiver can revoke the certificate. How will you do that?

If private key was compromised, in TLS none of previous messages can be decrypted, only future messages can be decrypted. How will you do that?

If an attacker intercepts the traffic and resends some packets again, the receiver in your case will not recognize it and will trust it. But in TLS it is impossible to resend the intercepted data, because they will be rejected by the sender. How will you do that?

I'd suggest you to use TLS instead of trying to solve all these problems in the own implementation.

  • We will use HTTPS which will use TLS for the data in transmission over Internet but not all hops. But we are also encrypting the data itself. Imagine a RESTful Request. So using https, this message could be sent from server to client. { message: < this data encrypted > } And the client must decrypt this. ... Also the client could send this data to the API { message: < this new data encrypted > } The API must decrypt it. TLS over HTTPs is this what you meant only? This is not good enough as not all transmission and the payload itself may flow through other sys Feb 14, 2023 at 15:21
  • But I think you answered the question in point 1. So possibly 4 keys in total Feb 14, 2023 at 15:23
  • I though, you want to implement an own encryption instead of using TLS. But actually you need an end-to-end encryption. Then it is fine that you want to encrypt the message. But also in this case I'd suggest you to use PKI and to pay attention to the part 3. Use certificates for every party (it should be certificate for encryption, not for TLS). Certificates will allow validation mechanism, also they will allow revocation. Also use nonce, it will prevent replay attacks in case some of intermediate nodes is malicious.
    – mentallurg
    Feb 14, 2023 at 20:31

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .