3
$\begingroup$

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!

$\endgroup$

migrated from stackoverflow.com Jan 14 '17 at 9:21

This question came from our site for professional and enthusiast programmers.

  • $\begingroup$ I thought about using B identity as the key. But how to keep this secret from SP until the event. $\endgroup$ – user2709214 Jan 14 '17 at 16:54
  • $\begingroup$ Questions: does A know the identity of B when he deposits the data? If B is able to decrypt the data, could C (who pretends to be B) decrypt it as well? If not, what distinguishes the real B from the fake (or from the SP)? $\endgroup$ – poncho Jan 16 '17 at 16:28
  • $\begingroup$ A knows the identity of B. But B may or may not know A. Your observation on a fake B is warranted. We may need to involve B at encryption time but it could be a significant amount of time between encryption and the event that triggers decryption. We don't want to chance that B cannot decrypt. It is desired but not necessary to prevent a counterfeit B after the event but it must be prevented before the event. $\endgroup$ – user2709214 Jan 16 '17 at 17:00
1
$\begingroup$

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

$\endgroup$
  • $\begingroup$ @EllaRose: The "public key approach" vs the "Ted and Trent: two trusted hosts" approach are intended to be very different answers. The stuff before that is identical and meant to be general comments on the original question, but I couldn't figure out how to summarize that stuff short enough to fit in the "comment" field under the original question. $\endgroup$ – David Cary Jan 16 '17 at 18:49
  • $\begingroup$ David, please let me chew on this a bit. Bob keeping the private key seems effective. It does require his cooperation at encryption time. The approach does allow multiple recipients of the encrypted data and is host proof which is strongly desired. My only reservation is that it is possible that in the interim between encryption and event Bob may lose his private key and I would like to insure against that. $\endgroup$ – user2709214 Jan 17 '17 at 19:17
  • $\begingroup$ This protocol doesn't require Bob to do anything at encryption time, if Bob has previously published his public key at any public key server. $\endgroup$ – David Cary Jan 18 '17 at 2:06
  • $\begingroup$ David, I agree and think this can work even if we have to have each Bob register a public key and emphasize that they will need their private key for decryption, or some variation of this. I thank you for your input and I'm makring this as the answer. $\endgroup$ – user2709214 Jan 19 '17 at 3:37
1
$\begingroup$

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

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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