Comment by eis | Hacker News Reader

Comment by eis | Hacker News Reader

I was curious how this could work and spotted this sentence in the README:

> In practice this means that if you trust there are never more than the threshold t malicious nodes on the network you're relying on, you are guaranteed that you timelocked data cannot be decrypted earlier than what you intended.

So I guess this just relies on a multi key threshold scheme where t nodes have to combine their keys to decrypt the data. And I assume the blockchain tries to punish participants who refuse to take part in the decryption?

If so then this seems very tricky in terms of risk because if you have more than t malicious nodes they can secretely collude outside the chain to decrypt the data before the specified time and you'd never know in contrast to the usual attacks on blockchains which are very obvious. So the chain in that regard does not and can not add to keep the actors honest in that regard.

Would love to see the DEF CON presentation but I couldn't find a video for it. Didn't even spot it in the DEF CON timetable.

Yes and no: it's not a blockchain. It's relying on the fact that the drand network is producing distributed, verifiable randomness using a threshold scheme with distributed key generation. So the secret key of the group is never in memory on any device and the only way to obtain a valid signature for a message is by having a threshold number of "partial signatures" being produced by the drand nodes in the network. Currently it relies on the League of Entropy network, run by Cloudflare, Protocol Labs, Ethereum Foundation, Kudelski Security and other organizations, including multiple universities. So the security is relying on the fact that the network's goal is to produce public randomness, and that parties have no reason to collude. For instance the League of Entropy is used for leader election and randomness by Filecoin, so it's already "securing" a lot of things, adding timelocked data on top seems like a nice way to use the network. And yeah, if there are ever a threshold of nodes colluding to produce a signature "too early", that's sadly not detectable.

Thanks for sharing these randomness sources, will have to explore them.

To me the beautiful thing about trying to get randomness is that as long as you have one random source then you have randomness. I.e. non-random XOR random => random.

So, you use X sources, as long as one of them is truly random then you are golden. Even if most are compromised it shouldn’t matter. Use on device security chip randomness, use user input, use external party providers etc. it all helps! (But be careful to errors when implementing, that’s hard to do!)

> To me the beautiful thing about trying to get randomness is that as long as you have one random source then you have randomness. I.e. non-random XOR random => random.

Only if the sources choose their numbers independently of each other. If the non-random is a function of the random source (e.g. the identity), then the result isn't random, it's a constant 0.

Also, be careful of a "last player attack" when XORing randomness: if your last source could spy on the state of your buffer, or on all other randomness sources, it can trivially craft a string that would XOR to a specific value once XORed with the other sources.

> Yes and no: it's not a blockchain. It's relying on the fact that the drand network is producing distributed, verifiable randomness using a threshold scheme with distributed key generatio

Hm ok, it's just that there is a lot of blockchain terminology used throughout drand like "testnet", "mainnet", "chain" and so on. Seems very similar to a blockchain with similar attack scenarious but I guess it's not exactly a blockchain but somewhat similar?

> Currently it relies on the League of Entropy network, run by Cloudflare, Protocol Labs, Ethereum Foundation, Kudelski Security and other organizations, including multiple universities. So the security is relying on the fact that the network's goal is to produce public randomness, and that parties have no reason to collude. For instance the League of Entropy is used for leader election and randomness by Filecoin, so it's already "securing" a lot of things, adding timelocked data on top seems like a nice way to use the network.

I see so there is a closed group of more or less well known entities which hopefully wont be dishonest to a major degree. Closed group being the key here because that prevents whole range of attacks, most importantly sybil attacks. So the trust in the system derives from the trust into the participants.

Without researching it more I would guess that during encryption it might use the public keys of the nodes plus the round number with the threshold scheme and when the round finally arrives, the nodes then publish their private keys for this round?

I think I have a better idea of the system now. Judging by me being not the only one here who didn't understand how things work on a high level maybe the README could be expanded a bit. That would be great.

One of my old friends had a fun idea for time locked encryption using a satellite, by broadcasts public keys and then the matching private keys after a fixed amount of time.

Probably requires too much trust in the satellite's builders, but it's a fun idea...

How does using a satellite broadcasting differ from a server on the internet publishing the keys? Both are single points of truth that you'd have to fully trust.

I would guess that a satellite can literally just have a TX radio on this module, so as long as you trust it to have been built and launched securely it can't be tampered with by anyone without space capability?

Whereas a server on the internet could be compromised over the internet.

You could have a server that only sends to the network as well. Just block everything apart from outgoing UDP packets. For the price of development and launch of such a satelite you'd probably be able to afford to make a custom hardware box with hardware random number generator that can physcally only send. In both cases you'd have to fully trust someone to have set up the system correctly. Both wouldn't be something I'd want to rely on.

Reply on news.ycombinator.com