Securing Data via secret key that must be revealed later

Question

This question is language and platform independent.

Assumptions: I am a service provider and my service is storing data encrypted with a key that my customer knows - but I do not.

My customer (party A) wants me to retain this data to a specific time then release the data to another party (party B) who does not know the decryption key.

I should never be able to decrypt the data myself - even writing code to do so.

The initial customer is unavailable and unable to pass the decryption key on to party B. It is my job as the service provider to provide a way for party B to decrypt the data.

Because party A cannot share the decryption key with party B ahead of time.

The catch is it must be impossible for me to know this decryption key and I must not be able to decrypt this data myself. A computer program can do this - that is allowed - but there must be no way for me to manipulate the data stored and decrypt it.

It would be a simple matter to store the decryption key and pass it on at the proper time, but I would then have access to decrypt the data and I do not want to even have that option. So how do we keep the decryption key secret until time for the exchange and exchange it without revealing it to me?

Edit: ideally B should have to do nothing. B may not even be aware of the situation until it becomes necessary to decrypt the data. This is the reason for the SP - but the SP cannot be able to decrypt. SP is necessary to prevent B from accessing data prematurely and to facilitate decryption by B. When it is time for B to decrypt A cannot be involved.

Purpose: protect data exchange from a to b where through dishonesty or coercion it is impossible for the SP to compromise the data and where a is no longer able to grant access to the decryption keys. Impossible?

The root question is: is there a scheme by which SP can encrypt data and convey decryption info to B without being able to use the decryption key.

The solution can be complex. SP doesn't have to know the link between the keys and the data or the links between data and recipient but when event occurs that releases the data then B must be able to decrypt. It must be impossible to decrypt before event.

How can this be accomplished?

Thanks!

Answer 1

If I understand you correctly, you want to set up a system such that

• Alice stores encrypted data on Ted's servers
• Some event occurs that tells Ted to do something.
• Sometime before that event, Alice has disappeared and becomes unable to perform any other steps in the protocol.
• Everyone wants Bob to recover the plaintext of Alice's data after the event.
• Ted is never able to recover the original plaintext. (In other words, this is a "host-proof" protocol. See host-proof for many related questions and answers).
• Bob is not able to recover the original plaintext before the event, only after Ted cooperates by doing ... something.
• Bob doesn't need to actively communicate with Bob or Ted or even know Alice exists before the event.

It seems clear to me that Bob needs to know (or be able to find out) something that Ted doesn't know. If Ted hypothetically knows everything that Bob knows, then by the time Bob receives a message from Ted and has all the information needed to decrypt the data, Ted has long before that time already has all the information needed to decrypt the data, which means that hypothetical protocol fails to be host-proof.

It also seems clear that we must trust Ted to actually send something to Bob after the event. If hypothetically both Alice and Ted refuse to communicate after the event, then Bob won't learn anything that he doesn't already know, and therefore either Bob has long before the event already had all the information he needs to recover the plaintext, or else he never is able to recover the plaintext -- both undesired.

Off the top of my head, one possible approach could be:

public key approach

• Alice somehow obtains Bob's public key.
• For each encrypted document Alice stores on Ted's servers, Alice encrypts the (symmetric) key used to encrypt that document using Bob's public key.
• Alice also stores each of those encrypted keys on Ted's servers. (The standard approach is to package both the encrypted document and several copies of the symmetric key, one copy encrypted using Alice's public key and another copy encrypted using Bob's public key, etc., in a single file in OpenPGP format).
• After the event, Ted sends those packaged encrypted documents to Bob. (In principle, Ted could break those packages into 2 parts, the big encrypted data part and the small encrypted symmetric key part, and send either one or the other -- but not both -- to Bob ahead of time).
• Once Bob receives both the encrypted data and the encrypted symmetric key, Bob uses Bob's private key to decrypt and recover Alice's plaintext data.

Because Ted never has Alice's private key or Bob's private key, Ted is unable to recover the original plaintext on his own.

Because Bob needs both the big encrypted data part and its decryption key to recover the plaintext, Bob is unable to recover the original plaintext before Ted sends him both parts, and we trust Ted not to do that before the event.

Answer 2

If I understand you correctly, you want to set up a system such that

• Alice stores encrypted data on Ted's servers
• Some event occurs that tells Ted to do something.
• Sometime before that event, Alice has disappeared and becomes unable to perform any other steps in the protocol.
• Everyone wants Bob to recover the plaintext of Alice's data after the event.
• Ted is never able to recover the original plaintext. (In other words, this is a "host-proof" protocol. See host-proof for many related questions and answers).
• Bob is not able to recover the original plaintext before the event, only after Ted cooperates by doing ... something.
• Bob doesn't need to actively communicate with Bob or Ted or even know Alice exists before the event.

It seems clear to me that Bob needs to know (or be able to find out) something that Ted doesn't know. If Ted hypothetically knows everything that Bob knows, then by the time Bob receives a message from Ted and has all the information needed to decrypt the data, Ted has long before that time already has all the information needed to decrypt the data, which means that hypothetical protocol fails to be host-proof.

It also seems clear that we must trust Ted to actually send something to Bob after the event. If hypothetically both Alice and Ted refuse to communicate after the event, then Bob won't learn anything that he doesn't already know, and therefore either Bob has long before the event already had all the information he needs to recover the plaintext, or else he never is able to recover the plaintext -- both undesired.

Off the top of my head, one possible approach could be:

Ted and Trent: two trusted hosts

• For each document, Alice generates a random symmetric key, encrypts the document with that symmetric key, and stores the resulting encrypted document on Ted's server or Trent's server or both.
• For each encrypted document, Alice encrypts the (symmetric) key used to encrypt that document using a one-time pad. This splits the key into 2 pieces -- an encrypted symmetric key, and a piece of one-time pad that can later be used to decrypt it. (This is "trivial secret sharing". Any other secure form of secret splitting would also work. Other forms of secret splitting might work even better).
• For each encrypted document, Alice stores one piece of the split key on Ted's servers and the other piece on Trent's servers, but never sends all the pieces of the split key to any one person.
• After the event, both Ted and Trent send all data they got from Alice to Bob. (In principle, Ted and Trent could send all the encrypted documents to Bob ahead of time, and send either one part of the split key or the other -- but not both -- to Bob ahead of time).
• Once Bob receives the encrypted version of a document and all the pieces of a split key for that document, Bob combines the split key to recover the original symmetric key, then uses that symmetric key to recover Alice's plaintext document.

Given the initial constraints, I don't see any way around trusting Ted not to reveal some information to Bob prematurely. This protocol has the additional weakness of trusting Ted not to (ever) reveal information to Trent, and also vice-versa.