Are there any algorithm out there that implements following scenario?

  1. Create a master private key
  2. Create a private/public key #1 based on the master key
  3. Create a private/public key #2 based on the master key
  4. Encrypt data #1 with public key #1
  5. Encrypt data #2 with public key #2
  6. Possible to decrypt data #1 with both private key #1 and master key
  7. Possible to decrypt data #2 with both private key #2 and master key
  8. Impossible to decrypt data #1 with private key #2
  9. Impossible to decrypt data #2 with private key #1
  • 1
    $\begingroup$ The simple-minded inefficient way is just to encrypt the data twice: once with the master key, and once with the subkey. A slightly less inefficient way is to use that to conceal a per-message secret key, which either the master private key or the private subkey can recover, and use the per-message secret key to encrypt the message with an AEAD. A much fancier way is to use a ‘hierarchical key derivation’ scheme, but you should start with the simpler less efficient ways because you can build them out of standard tools, unless you have performance constraints that make them unusable. $\endgroup$ Apr 7, 2018 at 17:13
  • $\begingroup$ Yes, there is performance and disk space/disk io/network io limitations as a lot of data should be encrypted, and encrypting twice is not a choice. I'll google AEAD to understand what is it. Thanks. $\endgroup$ Apr 7, 2018 at 20:11
  • $\begingroup$ AE(AD) is authenticated encryption (with associated data). Standard examples: AES-GCM, crypto_secretbox_xsalsa20poly1305. You should try to find estimates of how much disk space and how much bandwidth you have available, and how much data you will need to store/transmit; can't work with ‘a lot’. In some scenarios, a kilobyte is a lot; in some scenarios, an exabyte is a lot. $\endgroup$ Apr 7, 2018 at 20:49
  • 1
    $\begingroup$ Distantly related (depending on the exact scenario) : Does any public key crypto support and/or allow a 3rd party “control-key”? $\endgroup$
    – e-sushi
    Apr 8, 2018 at 14:55

1 Answer 1


You're looking for "key escrow", which is often a very bad idea. Even if this fits your use case, you're creating a single point of failure.

I'm sure that there are more sophisticated approaches, but here is a very simple one:

You need a pseudorandom function (PRF) and a public key encryption scheme.

Draw a random key $k$ for the PRF and use it as master key. Then whenever generating a public/private key pair, take a unique bitstring $id$, compute $PRF(k,id)$ and use the result as randomness for the key generation algorithm of the public key encryption scheme, which gives you a private key $sk$ and a public key $pk$. Store a table that maps $pk$ to $id$.

This fulfills everything that you want: As long as the key $k$ is not revealed, the public key encryption scheme works as intended and is secure. But if I know $k$, I can look $id$ up in the table, recompute $PRF(k,id)$, derive $sk$ and decrypt.

Here, $id$ is a nonce in the weak sense: it can either be fully random or implemented by a counter; you "just" need to make sure that it is never repeated. (If it is a counter, you can also not store the table in the first place, and just try enough counter values until you have the right one, if you need to decrypt rarely with the master key.)

  • $\begingroup$ Perfect. I've checked it out and it worked as scenario. Thank you. Also you are perfectly right, key escrow is a bad idea, but sometimes it's the only way to implement security (because of regulations in some countries, or policies in some companies). I just changed the scenario in above question, which could be more secure because of how keys are generated. Maybe you could help on it too: crypto.stackexchange.com/questions/58191/… $\endgroup$ Apr 8, 2018 at 9:02
  • $\begingroup$ Note that I've just edited. Previously it said that the public key should contain id, which is wrong of course. $\endgroup$ Apr 8, 2018 at 9:56
  • $\begingroup$ I don't have enough reputation to comment on your question but what's the point of having a master public key? It's not used in your scenario. If you want that it's possible to encrypt a message only to the "master" party, then just derive a normal key for it. $\endgroup$ Apr 8, 2018 at 10:00
  • $\begingroup$ "Master public key" can be used to generate new subkeys. So we can hide master private key somehow (like saving it somewhere that nobody can access it, but can be retrieved in emergency cases). So hacker (or evil employee with access to the server) can't decrypt data. $\endgroup$ Apr 8, 2018 at 14:41
  • $\begingroup$ Search for "identity-based encryption". $\endgroup$ Apr 8, 2018 at 19:20

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.