A censorship resistant deadman's switch • Hacker News Board

Re: A censorship resistant deadman's switch

#21

Post by rtkwe » Wed, Apr 25, 2018, 6:05 PM UTC

robert-wallis wrote: post #7

What if the miners deny check-in transactions to force the killcord to execute?

The whole idea is kind of predicated on whoever you're worried about attacking you not wanting the information to get out more than they care about getting to the person holding the dead man's switch. If they are more concerned with getting to that person than with whatever information the person has threatened to publish no level of security on the switch matters it just becomes part of the cost of getting to the owner.

Re: A censorship resistant deadman's switch

#22

Post by VectorLock » Wed, Apr 25, 2018, 6:11 PM UTC

danShumway wrote: post #9

wyas wrote: post #6

Earlier quoted context omitted.

Quick browse seems to be like so: 1. Client generates necessary files (including keys and payloads). 2. Encrypted payload is placed on IPFS. 3. Keys are placed on a trusted published (potentially single point of failure). 4. A smart contract running on the EVM continuously checks for pings from clients. If client doesn't check in over some pre-defined policy, then trusted published will be aware and publish keys to t…

Is that... good? I mean, I understand that security isn't black and white, and really you're just trying to make it harder for someone to attack you, not impossible. But how much do you gain by decentralizing just the trigger? Since the trigger logic fundamentally relies on you doing something, it seems like that logic could be local to machine, your machine could query any number of public websites/platforms/IPs and…

Its basically treating Ethereum as an anonymous signal bus.

Re: A censorship resistant deadman's switch

#23

Post by VectorLock » Wed, Apr 25, 2018, 6:14 PM UTC

robert-wallis wrote: post #7

What if the miners deny check-in transactions to force the killcord to execute?

You're boned. Then most systems including Ethereum are based on the assumption that the miners aren't majority controlled by an adversary. That may or may not be a sound assumption.

Re: A censorship resistant deadman's switch

#24

Post by dooglius » Wed, Apr 25, 2018, 6:28 PM UTC

danielvf wrote: post #11

danShumway wrote: post #9

Earlier quoted context omitted.

Is that... good? I mean, I understand that security isn't black and white, and really you're just trying to make it harder for someone to attack you, not impossible. But how much do you gain by decentralizing just the trigger? Since the trigger logic fundamentally relies on you doing something, it seems like that logic could be local to machine, your machine could query any number of public websites/platforms/IPs and…

The one attack that I can see it blocking is that it allows for 100% untraceable monitoring [edit: of the deadman's switch by the the system-that-should-send-the-message]. Since every bit of data pushed to Ethereum goes to every single full node, you can't find out who has the keys to the secret data and will release them.

No, the message sending system still needs to actually send the message to the network at some point, which gives away the sender’s IP.

Re: A censorship resistant deadman's switch

#25

Post by carussell » Wed, Apr 25, 2018, 6:30 PM UTC

tshannon wrote: post #18

So a lot of these comments seem to be criticisms of potential vulnerabilities (which is par for hacker news really). I'm curious if there are better alternatives out there that aren't vulnerable to the same issues, like a single point of failure or attack?

You could do secret splitting:

http://www.moserware.com/2011/11/life-death-and-splitting-se...

It's vulnerable in that whichever threshold N that you choose allows for N participants to conspire to publish ahead of time, or M - N to conspire not to publish after the fact.

Re: A censorship resistant deadman's switch

#26

Post by gnode » Wed, Apr 25, 2018, 6:32 PM UTC

Given that the trusted party is required for this to work, is there any point at all in having it depend on the Etherium blockchain, other than perhaps a weak form of anonymity network?

Re: A censorship resistant deadman's switch

#27

Post by fareesh » Wed, Apr 25, 2018, 6:47 PM UTC

Does this take into account network congestion and such?

Re: A censorship resistant deadman's switch

#28

Post by alanh » Wed, Apr 25, 2018, 6:49 PM UTC

carussell wrote: post #25

tshannon wrote: post #18

So a lot of these comments seem to be criticisms of potential vulnerabilities (which is par for hacker news really). I'm curious if there are better alternatives out there that aren't vulnerable to the same issues, like a single point of failure or attack?

You could do secret splitting: http://www.moserware.com/2011/11/life-death-and-splitting-se... It's vulnerable in that whichever threshold N that you choose allows for N participants to conspire to publish ahead of time, or M - N to conspire not to publish after the fact.

interesting. i hadn't seen this although I implemented something effectively the same, except that all keys (which could be any number ≥ 2) be combined to reveal the secret (or any information about it).

Re: A censorship resistant deadman's switch

#29

Post by microcolonel » Wed, Apr 25, 2018, 6:51 PM UTC

fareesh wrote: post #27

Does this take into account network congestion and such?

If you can manage not to tell anyone what address the thing is running on.

Re: A censorship resistant deadman's switch

#30

Post by shadowfiend » Wed, Apr 25, 2018, 6:51 PM UTC

gnode wrote: post #26

Given that the trusted party is required for this to work, is there any point at all in having it depend on the Etherium blockchain, other than perhaps a weak form of anonymity network?

The trusted party can be factored into a decentralized network as well. This is what our team is working on with the Keep network (we've considered dead man switches as potential applications for a while).