Hacker News Reader

Comment by anomalroil | Hacker News Reader

Encrypting something that cannot be decrypted until a given future date is now possible :D This was presented on Friday at DEF CON, and there's also a web demo to try it out using the second compatible TS library: https://timevault.drand.love/

View on HN

How does this work really? Is this basically just putting someone on chain, presuming that there wont be a 51% attack, and relying on the chains normal block creation schedule? I presume this timelock can be cracked early if I spend enough compute resources on it.

Also I presume it doesn't work well for small time intervals (less than or equal to drand's block creation times)?

I have a healthy amount of skepticism of this approach.

the source code is on github https://github.com/drand/timevault

That is right and it is not explained in the README file. Timelick based on Blockchain is not a security primitive.

there is no blockchain involved at all

I used the term blockchain with liberty, it is based on a consensus mechanism so you need to assume the consensus is right which is different of timelock encryption usage in classic ways. The README was edited after the HN posts.

It's not really a consensus mechanism either really - the randomness in some sense is deterministic, it just requires participation. I'm unsure which 'classic ways' you're referring to - in principle it's not that different to having a notary, except the notary is a distributed network rather than a single entity.

> The README was edited after the HN posts.

You can see from that the tlock git history the README.md hasn't been updated in 13 days and the tlock-js one hasn't been updated in 4 days - both before the HN post. Are you talking about another README?

Sort of. It uses secret sharing so it's not based on computation power.

And I didn't see any, but if there is the capability of onboarding new members in the network, it requires bootstrapping a new chain, I think.

Onboarding new members on a drand network is fairly easy: there only needs to be a threshold of nodes doing a resharing ceremony and all nodes get new shares and new nodes can be onboarded like that. It's not handled by tlock or timevault, it's on the League of Entropy side and is how drand works. More details are in https://drand.love/docs/cryptography/

>Is this basically just putting someone on chain, presuming that there wont be a 51% attack

There is no chain or block creation. Also it's not a public permissionless network, so outside actors can't join for a sybil attack.

>I presume this timelock can be cracked early if I spend enough compute resources on it.

Sure like any cryptography, if you have more computing power than exists in the world

>Also I presume it doesn't work well for small time intervals (less than or equal to drand's block creation times)?

There is a dependence on transmitting shares between nodes in the network to gain a threshold number of share - right now each epoch is 30 seconds, but new networks could be created with down to ~1 second epochs

It works by relying on identity-based encryption to encrypt plaintext that cannot be decrypted until the signature of a specific message is revealed. The League of Entropy is signing its beacons every 30 seconds and so acts as a reference clock to provide the signatures on time.

In practice everything released at defcon sees its last commit within 24H prior of the presentation. An unfortunate reality.

Ahahah, definitively. Where's the challenge otherwise? The PoC was ready since almost 8 months sitting in a branch of drand/kyber, and the Go tlock library since a month or so and it would have been enough if it weren't for the DEF CON presentation that made a web-demo more appealing for people to try it out :P

Reply on news.ycombinator.com