3 ms·

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

by eis 4y ago

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.

sdenton4 4y ago
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...
- eis 4y ago
  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.
  - rawling 4y ago
    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.
    - eis 4y ago
      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.
anomalroil 4y ago
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.
- miketery 4y ago
  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!)
  - heinrich5991 4y ago
    > 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.
  - anomalroil 4y ago
    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.

by eis 4y ago

sdenton4 4y ago

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

eis 4y ago
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.
- rawling 4y ago
  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.
  - eis 4y ago
    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.

anomalroil 4y ago

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.

miketery 4y ago
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!)
- heinrich5991 4y ago
  > 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.
- anomalroil 4y ago
  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.