Ability to submit lock without revealing the time it can be decryted

[wighawag]

In my use case, the encryptor do not want the decryptor to know when decryption is possible. This is because in my use case, the timing needs to remains secret.

To avoid the decryptor to check the decryption at every epoch, one idea is that encryptor will provide the decryptor the minutes (and seconds) to check but will not tell the day/hour.

See conversation slack :

wighawag:
hey got a question on tlock. Is the decryption time public ?
if it is public by default, is there a way to ensure that only the one encrypting know when decryption will be possible ? (edited) 

Will Scott
you could not include the decryption time with the encrypted blob, but it would be up to recipients to trial-decrypt every epoch

wighawag
Nice, is the tlock-js library supporting that option easily ?

The idea is that for my use case, decryptor will be able  to try every hour

Will Scott
would you know that you are only encrypting at an hour granularity, or could encryption still be at any epoch?

Patrick McClurg (Protocol Labs)
right now tlock-js doesn’t enable this super easily - during encryption, the roundNumber is encoded into the AGE args and then used for retrieving the beacon during decryption time.It wouldn’t be super hard to make a fork though - you could e.g. put a round number of -1 and remove the bounds check, and change decryption to check every hour when the round number is negative

ofc it will not be compatible with the other tlock libs, but it sounds like that’s not a big deal for your use case!

wighawag:
@Will Scott, yes, basically, one idea is that the encryptor will be telling the minute (and seconds) the decryption will be ready but not the hour

@Patrick McClurg (Protocol Labs) I ll create an issue in tlock-js as I think it is a valid use case for it

Will Scott
makes sense. having a coarser quantization seems useful in not making decryptors do way too much work

If tlock-js could left out the decrypting time, application could provide their own mechanism

[nikkolasg]

If you are eager to do it yourself, things are already there in some form:

• Using the lowest crypto level here you can encrypt and decrypt 32 bytes.
• Then if you need to encrypt a larger message, you have to do your own encryption of the message with the key you encrypt with IBE (point 1) with age, or openssh or chachapoly whatever you prefer to use.

Like this, you won't have to get the round number inserted into the format already you just don't include it.
This library does it all for your so you don't have to care about these things, but they're not that hard to get right.

[AnomalRoil]

It should actually be as simple as not including the round number here (maybe put -1 instead? ):

tlock-js/src/drand/timelock-encrypter.ts

Line 20 in 4eb726a

args: [`${roundNumber}`, chainInfo.chainHash],

And then changing the decryption to specify the round number manually instead of parsing it:

tlock-js/src/drand/timelock-decrypter.ts

Lines 19 to 25 in 4eb726a

	if (args.length !== 2) {
	throw Error(`Timelock stanza expected 2 args: roundNumber and chainHash. Only received ${args.length}`)
	}
	// should probably verify chain hash here too
	const beacon = await network.get(parseRoundNumber(args))
	console.log(`beacon received: ${JSON.stringify(beacon)}`)

[wighawag]

Thanks @nikkolasg and @AnomalRoil for your input

I created this PR for it : #7

I tried to minimize breaking changes but due to optional args I had to make some,