lukevalenta

Here's how you can get that entropy using the Shannon entropy equation from https://en.wikipedia.org/wiki/Entropy_(information_theory).

Like you said, the probability of any digit appearing is 1/30, and there are 10 digits. The probability of a lower- or upper- case letter appearing is 1/78, and there are 26+26 = 52 letters.

Plugging that into the formula for Shannon entropy, we get this:

- 10 * (1/30) * log_2(1/30) - 52 * (1/78) * log_2(1/78) =~ 5.826

Some folks from Chainsafe looked into it a couple years ago: https://github.com/nulltea/zk-timelock. I'd love to see this work move forward.

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 :).

Randomness from a CSPRNG (cryptographically-secure random number generator) never really gets "depleted," since as long as the seed contains enough entropy and isn't compromised, then it's computationally infeasible to learn anything about the internal state of the CSPRNG from it's outputs. See https://research.nccgroup.com/2019/12/19/on-linuxs-random-nu... for a nice overview.

The Linux random number generator did used to have a notion of entropy depletion, but that is no longer the case (at least for x86-64 systems: https://wiki.archlinux.org/title/Random_number_generation).

On older systems that have a notion of entropy depletion, you would eventually deplete the entropy counter and /dev/random would start blocking if you aren't feeding new entropy into the system.

The piece that helps security-wise is that we're mixing in entropy from a trusted external source, so not solely relying on the local random number generation from a machine in a data center somewhere. Is it likely that local random number generation would be compromised? No. But it does give us a little extra peace of mind.

As long as it's done correctly, mixing new entropy sources into an entropy pool will never _decrease_ the entropy. So in the case of LavaRand, even if it only ever returned a string of zeros, systems that mix it's output into their entropy pools wouldn't be any worse off than before. Perhaps we could have made this point more clearly in the post. (I'm one of the authors.)

Correct. Anonymizing the U2F device hides the device manufacturer information, which is currently required for Cloudflare to verify that the device comes from a trusted vendor.

From the blog post: > Cloudflare asks you for proof and checks that your manufacturer is legitimate.

Regarding your second point, this is meant to be a CAPTCHA alternative, not full replacement. Users without access to approved devices should be able to fall back to existing proof of personhood mechanisms. It's good to have options!