2
$\begingroup$

I'm wondering if the following scheme (or something similar) can exist:

I want to encrypt a randomly generate a public key and secret key pair, $(pk, sk)$. I would like that $sk$ is encrypted some form of timelock encryption. My goals are:

  1. Nobody should be able to compute $sk$ before the timelock expires
  2. Anyone should be able to compute $sk$ after the timelock expires
  3. $pk$ should be public as soon as it is generated.

My (very vague) idea is that one uses some distributed protocol to create $sk$. Similar to the idea expressed here. This is now encrypted using a timelock encryption like this.

Can such a system exist?

$\endgroup$
3
  • 2
    $\begingroup$ I don't see a reason why your proposal wouldn't work but there are a few caveats. The distributed key gen ensures privacy of the secret key unless parties collide, but the TLE scheme you link to is also a threshold system. So it provides similar guarantees unless you trust the service provider less than parties in the DKG. If that's not a concern, you could directly rely on the identity based scheme of the TLE. If you assume no collusion then it's effectively does what you want. Downside is that it only works with Boneh-Franklin scheme. $\endgroup$ Jan 25 at 23:43
  • 2
    $\begingroup$ If the key pair is for an arbitrary PKE scheme: I suppose each party will encrypt their share with TLE? you probably want a good DKG, to prevent malicious parties to mess with key Gen and making sure the public key is consistent. You'll probably want some kind ZK proof of knowledge to make sure each encrypted share is OK and will allow decryption when the time comes. Does this address your question? $\endgroup$ Jan 25 at 23:48
  • $\begingroup$ @MarcIlunga, yes it answers the question. Specifically, the fact that assuming no collusion among the participants of the network, the secret key is known to no one before the timelock expires and publicly decryptable after the timelock expires. If you make your comments an answer, I'd be happy to accept. Thank you! $\endgroup$ Jan 26 at 10:45

1 Answer 1

2
$\begingroup$

The scheme proposed in the question looks reasonably possible but might require getting some details right and thinking more carefully about the desired security guarantees. On the other hand, it is also possible to rely on the time lock encryption (TLE) service directly, assuming the following:

  • The public key encryption scheme choice can be arbitrary.
  • The time lock encryption service is a threshold service (similar to the current deployment), and one can trust that most participants in that service behave honestly and follow the protocol.

Relying directly on the TLE service

The TLE service currently deployed already allows one to encrypt to a public key and enable decryption only after a certain time. The encryption scheme used is the Boneh-Franklin identity-based encryption scheme, where timestamps are identities, and a timestamp hash is the public key. Extracting the secret key looks like producing a BLS signature. Then, everything else comes together by the magic of pairings. The TLE service relies on a threshold BLS network, oblivious to the TLE shenanigans. Assuming enough parties in the BLS network behave honestly by only producing signatures for the relevant time stamps, the TLE service provides the guarantees the question requires.

Using a custom PKE/key generation scheme.

If the key pair is for a specific scheme, say HPKE, or if the users don't want to trust the BLS signing network out of fear enough parties might misbehave and try to learn the secret key before the appropriate time, then another distributed key generation scheme might be needed as described in the question. In this scenario, every party will then TLE encrypt their key shares. Some of the details to think carefully about:

  • Use a secure threshold distributed key generation scheme. We'll want to ensure that no party fully controls the outcome of the DKG and that there are no single points of failure. We'll also want to make sure that the outcome is consistent to prevent parties from sabotaging the DKG, which can lead to the permanent loss of a private key.
  • Ensure parties prove they TLE encrypted the right thing to guarantee decryption.
  • Other robustness measures that I probably forgot.

So it seems this scheme should use at least the following zero-knowledge proofs of knowledge.

  • Proof that each party knows the secret key share associated with their public key share (usually covered by DKG schemes).
  • Proof that TLE encrypted shares correspond to the public key shares.
$\endgroup$
2
  • $\begingroup$ Thanks for the great answer! Just one more comment - it seems like the TLE encryption is not quantum-resistant. Would you happen to know if there exist TLE schemes that are? $\endgroup$ Jan 26 at 19:43
  • 1
    $\begingroup$ @user1936752 Indeed, the scheme as is not post-quantum. There might exist some lattice based threshold randomness generation that mix with IBE schemes, or just TLE from lattices, but I am not knowledgeable about this. $\endgroup$ Jan 27 at 12:55

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.