[falsandtru]

Reading the cited Cloudflare blog, it seems that the main purpose of this technology is public randomness, and timelock is one of its applications. Since timelock is not the essence of this technology, it is not surprising that the usefulness of timelock is unclear.

> it’s become a reliable and production-ready core Internet service, relied upon by applications ranging from distributed file storage to online gaming to timestamped proofs to timelock encryption

Details: https://drand.love/docs/timelock-encryption/

Thread on the cited Cloudflare blog: https://news.ycombinator.com/item?id=39641475

[krackers]

If I'm understanding the Drand protocol correctly, then isn't the following quote from the Cloudflare blog misleading?

> Each organization contributes its own unique source of randomness into the joint pool of entropy used to seed the drand network – with Cloudflare using randomness from LavaRand, of course!

It leads you to think that the each round's random value comes from "combining" local sources of entropy that each node contributes, but skimming the actual Drand protocol used, isn't it closer to something like using AES-CTR as a PRNG, except instead of AES it's some particular threshold-signature scheme. From another cloudflare post

>To instantiate the required threshold signature scheme, drand uses the (t,n)-BLS signature scheme of Boneh, Lynn and Shacham. In particular, we can instantiate this scheme in the elliptic curve setting using Barreto-Naehrig curves. Moreover, the BLS signature scheme outputs sufficiently large signatures that are randomly distributed, giving them enough entropy to be sources of randomness. Specifically the signatures are randomly distributed over 64 bytes.

So "real-world randomness" only is mixed in during the very initial distributed key generation phase, and after that everything is purely deterministic right? Or put another way those fancy lava lamps are a non-sequitur since this scheme doesn't seem to rely on their values beyond the initial key generation?

[lukevalenta]

Hi, I'm one of the authors of the Cloudflare blog and maintainer of Cloudflare's drand nodes.

You're correct -- after the initial distributed key generation, the values produced by the drand network are deterministic (this is one of the properties that allows for timelock encryption). The security properties of drand rely on a threshold of nodes remaining uncompromised, but mixing in fresh randomness isn't necessary. (Although you could imagine having some drand chains that incorporate fresh randomness for properties like post-compromise security.)

> isn't the following quote from the Cloudflare blog misleading? >> > Each organization contributes its own unique source of randomness into the joint pool of entropy used to seed the drand network

If this is misleading it wasn't intentional! We used the word "seed" since the randomness from LavaRand is only mixed in when the network is initialized, but perhaps that could have been phrased better. Or perhaps we should have split it into separate blogs talking about LavaRand and drand since they're only tangentially related :).

[krackers]

Thank you for the reply, that clarifies things! As a crypto-novice perhaps explicitly using the term "initialize" might be better at indicating this is a one-time thing rather than a "continuous" process of injecting entropy.

[londons_explore]

I don't believe any such time lock encryption can take on any entropy after the user messages are encrypted - since by definition, any entropy in that randomness is useless for decryption if it wasn't involved in the encryption.