One Encryption, Many Decryption Keys I would like to share access to encrypted data among many recipients. I do not know the recipients ahead of time (when encrypting the data). Once the data is encrypted, I do not have access to the plaintext (so I cannot re-encrypt).

Right now, I have a shared secret key that is distributed to recipients as they are granted access to the data (again, encrypted so I do not have access ot the shared key). Unfortunately, that means any recipient of the shared secret can leak the key, compromising the data for everybody.

I can't really prevent "bad" recipients from the leaking the key (or the plaintext, for that matter), but I would like to be able to distribute unique keys to each recipient so that if a key is leaked, I can determine who did it.

I think I want a symmetric encryption scheme where the ciphertext can be decrypted by a set of keys, rather than a single key. Each secret key is unique and it's hard to derive one secret key from another (so one recipient cannot forge another's key), but its simple for me to generate new secret keys (so I can easily add new recipients).

Does such a schema sound familiar?
This is known in the cryptographic literature as "traitor tracing".  See, e.g., the following seminal paper:

An efficient public key traitor tracing scheme.  Dan Boneh and Matt Franklin.  CRYPTO 1999.

They show a public-key encryption scheme where each  possible recipient has their own private decryption key.  If an authorized recipient discloses their decryption key, it's possible for the authority to figure out whose key it was.  Moreover, they consider a further challenge -- what if a coalition of authorized recipients pool everything they know, and come up with another decryption key that is different from each of theirs but still works, and they leak that new key? -- and they show how to deal with that challenge as well.

There is an entire line of research that proceeds forward from there.



That said, this is often the wrong kind of solution in practice, for most situations.  You are assuming/hoping that the adversary will publish their decryption key.  But what if they don't?  What if they do something else?  There are all sorts of ways the adversary could cause problems without publishing their decryption key:


For instance, the adversary can leak the decrypted data without leaking the decryption key (this is the killer problem with all of these traitor tracing schemes that has rendered them mostly irrelevant in practice).
Alternatively, the adversary could make available an API that provides "decryption as a service".
Or, the adversary might release software for decryption that embeds the key but in an obfuscated form.


Traitor tracing doesn't help with any of those adversarial strategies.  So, beware that your threat analysis might be based on too narrow a view of what an attacker can do.

More fundamentally: this approach has seen no adoption in commercial systems (as far as I am aware), because of the extreme ease of acquiring false identities.  If you're going to sell access to paid content for $20, and you accept credit cards for payment, it's far too easy for someone to get a stolen credit card number, sign up and gain access, and then publish the decryption key (or the decrypted content).  Now what are you gonna do?  Even if you can trace back to the associated credit card number and name provided during signup, that name is surely fake, and the name on the credit card account is someone else.   At that point you realistically have no way to identify the perpetrator and no recourse.  All the fancy crypto in the world won't save you.

That's why these kinds of schemes might not be as useful as they at first appear, except in some special and limited circumstances.