How can multiple receivers decrypt message with public key

Question

If i encrypt a message with private key put the public key on server and send message to 2 enteties, how can the second one encrypt the message when the first one has the public key ?

Answer 1

Public key is meant to be namely public, means it should be available to everyone. I suppose that by saying that you put it to the server you mean you make it possible to download public key from your server.

Everyone who wants to decrypt your message will download public key from your server, where you put it, and will decrypt the message.

I'd suggest you to check the what you are trying to reach by such scheme.

• Confidentiality? Everyone will be able to decrypt such messages. That's why you cannot reach confidentiality by using such scheme. If you need confidentiality, i.e. if you want that nobody except the receiver is able to decrypt the message, then you can use other scheme: Use public key of receiver-1 to encrypt messages to receiver-1. Then nobody except receiver-1 will be able to decrypt them. Messages to receiver-2 encrypt with pubic key of receiver-2. I don't go on details about hybrid encryption here.
• Non-repudiation? It might be used for non-repudiation, because no one could produce such encrypted messages except you, the owner of the private key. Where as the idea is basically correct, a direct implementation would be insecure. See details here: encryption+decryption vs. signing. Instead of encryption+descryption use standard algorithms for digital signature like ECDSA.

Answer 2

As mentallurg says in his answer, the public key is meant to be public.

I assume the question you mean to ask is "How can someone send a message encrypted to two different recipients, using their public keys?"

The answer is hybrid encryption. The message itself is encrypted with a symmetric key, which I will call the "Data Encryption Key", or DEK for short. For each recipient, the DEK is then encrypted with the pubic key of the recipient. The public key, used to encrypt the DEK, is sometimes called the "Key Encryption Key", or KEK for short.

So, for a message sent to two recipients will look like this:

 Key Container 1    Key Container 2    Data Container
┌──────────────────┬──────────────────┬─────────────────────────┐
│ DEK, Encrypted   │ DEK, Encrypted   │ Data, Encrypted with    │
│ w/ public key of │ w/ public key of │ the Data Encryption Key │
│ Recipient #1     │ Recipient #2     │ (DEK)                   │
└──────────────────┴──────────────────┴─────────────────────────┘

The recipient will then see this message, and attempt to decrypt the first key container with every private key they have available. If decryption fails for all of them, they move on to the second container, then the third, and so on, until one of two things happens:

1. Every key container has been attempted and none could be decrypted.
2. One container could be decrypted successfully.

In the first case, the decryption fails. In the second case, the DEK will then be used to decrypt the data in question.

Answer 3

Skipping over the public-key / private-key mixup that @mentallurg addressed; what you are referring to is often called "hybrid encryption" or "enveloped data".

The core idea is this:

The main advantages here are:

• Performance: AES is much faster than RSA at bulk encryption, so even though there's an extra layer of crypto here, it's actually much faster for large documents.
• Key rotation: By decoupling the content encryption keys from the recipient's public keys, you can use a different AES key for each for each document, which is a good thing for a number of different reasons.

One of the cool things this scheme lets you do is add more recipients by simply giving them a copy of the AES data encryption key (DEK):

This is exactly how S/MIME email does it; you'll notice that the size of the encrypted attachment only grows a small amount as you add more recipients; that's because you're only adding another copy of the encrypted data encryption key (DEK), not re-encrypting the whole content.