1

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
e-sushi
  • 17,891
  • 12
  • 83
  • 229
  • 1
    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. – Squeamish Ossifrage Apr 07 '18 at 17:13
  • 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. – BravoCrypto Apr 07 '18 at 20:11
  • 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. – Squeamish Ossifrage Apr 07 '18 at 20:49
  • 1

1 Answers1

2

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.)

real-or-random
  • 423
  • 4
  • 10
  • 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: https://crypto.stackexchange.com/questions/58191/any-algorithm-with-a-pair-of-master-keys-and-multiple-pairs-of-subkey-for-asymme – BravoCrypto Apr 08 '18 at 09:02
  • Note that I've just edited. Previously it said that the public key should contain id, which is wrong of course. – real-or-random Apr 08 '18 at 09:56
  • 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. – real-or-random Apr 08 '18 at 10:00
  • "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. – BravoCrypto Apr 08 '18 at 14:41
  • Search for "identity-based encryption". – real-or-random Apr 08 '18 at 19:20