3

I can encrypt some data D using a random symmetric key K, obtaining a ciphertext C, and then encrypt K with my public key Pub and obtain H. So far so good: I can only decrypt C if I have H and my private key Priv. My goal is to only bring around Priv, and keep both C and H on a public server. Assume C is too large to be re-uploaded, and we do not trust the server so secure deletion is not possible.

The question is: what if Priv gets compromised? In the above scenario, nothing good. C will be on the server forever, together with H, leaving to the attacker the time to read C and decrypt it.

This is bad in comparison with e.g. a mail server, where I have to log in to view my data: as soon as I notice that my password has been compromised, I can change it, and if the attacker did not download C yet, I'm safe.

So the real question is: are there any known, or standard, methods to create "self-expiring symmetric keys"? What I imagine is that I could avoid to store H on the server, but still be able to derive H from some smaller secret (kept on the server) and some external "aid" which should be as simple and less trusted as possible, e.g. a random stream of data, in such a way that it is possible to reconstruct H only for a limited amount of time.

After the key is expired, the data would be lost. Before, one should be able to refresh the key.

Ilmari Karonen
  • 46,700
  • 5
  • 112
  • 189
vincenzoml
  • 131
  • 3

1 Answers1

4

I don't believe there is any way to achieve what you want, within your constraints.

You stated as a requirement that a user must be able to get all of their data from the server, without storing anything other than their private key. If an attacker learns the private key, the attacker then knows everything that the user does, so of course the attacker can decrypt too.

A random beacon (a continuous, public stream of random numbers) doesn't seem to help, since an attacker can record a copy of that entire stream. Also, it would rely upon on some external trusted party to generate the stream; if you are willing to trust a third party, there are simpler solutions. An example of such a solution: store $H$ on the trusted third party and return it only upon request to users who prove knowledge of the private key, and only if the expiration date has not yet passed.

A different solution is to have the user change their private key every so often. To ease this, they can generate a long-lived keypair which is used only for signing, and then generate short-lived keypairs every so often. The long-lived key is used to sign each short-lived public key and publish this certificate. To send a message to this user, you look up the current short-lived public key, check its corresponding cert, then encrypt to the short-lived public key. The user can then securely delete their short-lived keypair when it expires. (I think you might also be able to build sophisticated schemes that eliminate the need for a lookup, but I'm not 100% certain about that.)

D.W.
  • 36,982
  • 13
  • 107
  • 196