What prevent time-engineering ?

[X-Ryl669]

I'm probably misunderstanding the protocol, so please correct my assumptions below if I'm wrong:

1. tlock is using IBE to encrypt a message with the public string "Tomorrow 14:00" as public key.
2. The PKG is generating a private key for this public string and encrypting the message with this public key. Where does the private key goes?
3. The distributed random number network is used for what, how can you ensure it's ?
4. What prevent the recipient of the encrypted message to shift his clock forward, ask the PKG for the private key of "Tomorrow 14:00" and decrypt earlier ?

[CluEleSsUK]

Hi X-Ryl669,
I’ll take your questions in order!

tlock is using IBE to encrypt a message with the public string "Tomorrow 14:00" as public key.

tlock is indeed using IBE. The public key however the hash of the distributed randomness round number. The round number can be figured out be calculating the number of rounds that will have passed since the genesis of the network at the time you wish to decrypt, e.g. if the network genesis were midnight at 2022.01.01 UTC and you wished to encrypt something for midnight on 2022.01.02, and the network frequency was every 30 seconds, you’d use the hash of round number 2880.

The PKG is generating a private key for this public string and encrypting the message with this public key. Where does the private key goes?

the private key to decrypt the message is the signature over the randomness that will be released by the network at that round in the future - this is possible due to the properties in IBE.

The distributed random number network is used for what, how can you ensure it's ?

Following from the last question, the distributed randomness network is used to emit the random numbers and signatures that are used to decrypt timelock encrypted ciphertexts

What prevent the recipient of the encrypted message to shift his clock forward, ask the PKG for the private key of "Tomorrow 14:00" and decrypt earlier ?

Nodes on the network emit encrypted shares of the randomness every epoch that other nodes use to construct the randomness beacon.
If there is only a single node in the network and you convinced them to emit their share (well, really the whole beacon for a single node network!) for tomorrow right now, indeed you would be able to decrypt tomorrow‘s message. This is the reason we use a network of nodes - in order to decrypt something early, you’d need to convince a threshold number of nodes to cooperate maliciously with you and that ought to be quite hard.

We‘ll be releasing a blog post on timelock encryption in the next few weeks, but hopefully this will give you enough food for thought in the meantime!

[X-Ryl669]

Thanks for your answer!

So, if I understand correctly, you encrypt using a public key "H(random generator's round number)" and the private key isn't known yet, since it'll only be known when the network has reached such round number. Yet, I still don't understand the security here.

The PKG in IBE system has a master key which can decrypt/encrypt anything (since it can generate any private key so obviously the key for H(round number))

I understand that the drand network should be quite safe if the number of node is high enough with BLS signature scheme with the threshold, but it's not running the IBE, right ?

Who's running the IBE and how do you guarantee the master key isn't compromised ?

[AnomalRoil]

The IBE scheme used is described in section 4 of Boneh and Franklin's paper "Identity-Based Encryption from the Weil Pairing". We effectively use the League of Entropy as a PKG, where the ID is the hash of the round number, and the master secret is that of the League of Entropy (generated using Pedersen distributed DKG), P_Pub is the League's network public key and the private keys d_ID are basically the aggregated BLS signatures of the rounds that the League emits regularly.

The master secret key is therefore protected behind the threshold assumption, since it's never in memory on any computer, was generated using a distributed key generation algorithm and is getting reshared whenever we need to onboard new League members or want to refresh every nodes' shares, which we do to ensure that a compromise of a few nodes at a time wouldn't lead to a future compromise of the whole network.

If there ever is a threshold number of malicious nodes that are malicious all at once, the master secret key would be compromised and that would allow to decrypt anything, indeed.

PS: we're working on a pre-print with all the details, expect that in the next 2 months.

[X-Ryl669]

Ok, it makes sense. So, it means that you can decrypt a ciphered message if a number of node higher than the threshold decide so (page 22 of the cited paper, last paragraph). I guess it's correct with the assumption that most node will be fair. But what about a few malicious node that are injected/created regularly ?

How do you ensure such number of nodes never happen to exists ?

As far as I understand, even if you reshare the Shamir's secret keys regularly, malicious node could accumulate, over time, enough share to compute Shamir's polynomial and extract the main secret/private key, right ?