Public-key algorithms such as RSA or ECDSA have exactly one private key for each public key and vice versa.

Attribute-based encryption works (a little bit) like that. You have only one public key which is used to create all ciphertexts and you select the users that should be able to decrypt the data based on a policy of attributes. The policy can be a boolean formula and the users have secret attribute keys that should satisfy the policy if they must be able to decrypt the ciphertext.

If you use only one attribute for all users and a trivial policy containing that attribute, you've got that system that you wanted, but now the problem becomes that the user attribute secret keys have to be generated by a central server and you will need multi-party computation to get rid of the key escrow.

This is almost certainly too complicated for your case. You can simulate your intended system by encrypting the data with AES using a randomly generated key, then encrypt the AES key with all the public keys of the intended recipients. Concatenate everything into one package and send it on its way.

Let's say multiple recipients have (a different) private key and all of them can decrypt data encrypted with the same public key. You should ask yourself, how can the different private keys be generated to arrive at the same public key, but where all the recipients wouldn't know the private key of each other.

Public-key algorithms such as RSA or ECDSA have exactly one private key for each public key and vice versa.

Attribute-based Encryption

Attribute-based encryption works (a little bit) like that. You have only one public key which is used to create all ciphertexts and you select the users that should be able to decrypt the data based on a policy of attributes. The policy can be a boolean formula and the users have secret attribute keys that should satisfy the policy if they must be able to decrypt the ciphertext.

If you use only one attribute for all users and a trivial policy containing that attribute, you've got that system that you wanted, but now the problem becomes that the user attribute secret keys have to be generated by a central server and you will need multi-party computation to get rid of the key escrow.

Conventional

This is almost certainly too complicated for your case. You should use a symmetric algorithm like AES and a public key encryption algorithm like RSA in conjunction. You can simulate your intended system by encrypting the data with AES using a randomly generated key, then encrypt the AES key with all the RSA public keys of the intended recipients. Concatenate everything into one package and send it on its way.

Thoughts

Let's say multiple recipients have (a different) private key and all of them can decrypt data encrypted with the same public key. You should ask yourself, how can the different private keys be generated to arrive at the same public key, but where all the recipients wouldn't know the private key of each other.

Public-key algorithms such as RSA or ECDSA have exactly one private key for each public key and vice versa.

Attribute-based encryption works (a little bit) like that. You have only one public key which is used to create all ciphertexts and you select the users that should be able to decrypt the data based on a policy of attributes. The policy can be a boolean formula and the users have secret attribute keys that should satisfy the policy if they must be able to decrypt the ciphertext.

If you use only one attribute for all users and a trivial policy containing that attribute, you've got that system that you wanted, but now the problem becomes that the user attribute secret keys have to be generated by a central server and you will need multi-party computation to get rid of the key escrow.

This is almost certainly too complicated for your case. You can simulate your intended system by encrypting the data with AES using a randomly generated key, then encrypt the AES key with all the public keys of the intended recipients. Concatenate everything into one package and send it on its way.

Public-key algorithms such as RSA or ECDSA have exactly one private key for each public key and vice versa.

Attribute-based encryption works (a little bit) like that. You have only one public key which is used to create all ciphertexts and you select the users that should be able to decrypt the data based on a policy of attributes. The policy can be a boolean formula and the users have secret attribute keys that should satisfy the policy if they must be able to decrypt the ciphertext.

If you use only one attribute for all users and a trivial policy containing that attribute, you've got that system that you wanted, but now the problem becomes that the user attribute secret keys have to be generated by a central server and you will need multi-party computation to get rid of the key escrow.

This is almost certainly too complicated for your case. You can simulate your intended system by encrypting the data with AES using a randomly generated key, then encrypt the AES key with all the public keys of the intended recipients. Concatenate everything into one package and send it on its way.

Let's say multiple recipients have (a different) private key and all of them can decrypt data encrypted with the same public key. You should ask yourself, how can the different private keys be generated to arrive at the same public key, but where all the recipients wouldn't know the private key of each other.