Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A censorship resistant deadman's switch

killcord.io

Post reply on HN
Print view View original

31–40 of 69 posts

Re: A censorship resistant deadman's switch

#31

Post by danielvf »

dooglius wrote: post #24
danielvf wrote: post #11

Earlier quoted context omitted.

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.

Fixed my post. You are correct - just one side is secure.

Re: A censorship resistant deadman's switch

#32

Post by XR0CSWV3h3kZWg »

There is a lot of hate for the trusted party set up of this, which seems reasonable.

It seems like you could create a dead man's switch using arbitrary participants. You distribute a secret to every participant and then to attempt to activate the dead man's switch they raise k to the power s mod p and pass it to the next participant. As long as you act as a participant each time and raise the passed value to some invalid s then the answer that is arrived at won't be the final secret.

As long as you participate every round the wrong answer will be arrived at, but as soon as you don't participate the right answer will be arrived at.

Any singular party refusing to cooperate would destroy the deadman's switch so malicious activation would be tough.

Designing it so it can tolerate failures would be the hard part.

EDIT: I am wrong, this isn't that great. It's really hard to hide information that can be recovered without a secret being revealed.

Re: A censorship resistant deadman's switch

#33

Post by eridius »

XR0CSWV3h3kZWg wrote: post #32

There is a lot of hate for the trusted party set up of this, which seems reasonable. It seems like you could create a dead man's switch using arbitrary participants. You distribute a secret to every participant and then to attempt to activate the dead man's switch they raise k to the power s mod p and pass it to the next participant. As long as you act as a participant each time and raise the passed value to some inv…

What's the stop the other parties from simply running a round without you in order to find out what the secret is?

Re: A censorship resistant deadman's switch

#34

Post by danShumway »

XR0CSWV3h3kZWg wrote: post #32

There is a lot of hate for the trusted party set up of this, which seems reasonable. It seems like you could create a dead man's switch using arbitrary participants. You distribute a secret to every participant and then to attempt to activate the dead man's switch they raise k to the power s mod p and pass it to the next participant. As long as you act as a participant each time and raise the passed value to some inv…

So, sort of like a secret generating linked list, where one node (you) are a bad actor?

What prevents the participant right before you from simply circumventing you or secretly passing to the next participant directly?

It also seems that once someone receives the correct answer for their step in the chain, they no longer need anyone beneath them?

(A) -> (B) -> (C) -> (you) -> (D)

Once C has participated in this one time, why do they need A or B?

Re: A censorship resistant deadman's switch

#35

Post by xg15 »

wyas wrote: post #13
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…

There's a bunch of attack vectors, but most fall on the trusted publisher and client itself. IPFS and Ethereum are, by assumption (difficulty wise), ``secure''. Assuming both client and publisher's internal systems are intact, then you have two attack vectors: There's the false positive attack vector, where you can shut down the client's network access and force the secret to be prematurely leaked. There's the false…

I imagine the second attack may be mitigated by the fact that the publisher might be easier to hide than with direct access. E.g., if your dead man's switch were just some daemon running on a machine somewhere that you have to ping periodically, attackers could find the IP address of the daemon by watching your network traffic.

In the OP, you and the daemon (aka the trusted publisher) communicate exclusively via the blockchain, so it will be a lot more difficult to find the daemon's location.

Not sure if this is in any way better than just accessing the daemon through Tor though.

Re: A censorship resistant deadman's switch

#36

Post by IncRnd »

danShumway wrote: post #5

This is interesting, but runs contrary to my understanding of how Etherium works. I'm clearly missing something, any chance you (or anyone else) could elaborate more? My understanding was that the decentralization of Etherium would mean that everyone watching the contract would need a copy of the decryption key. If that's the case, what prevents someone from publishing keys early? Or is it that the key isn't stored i…

Killcord is described as resilient and resistant. The resilience is undefined, and the resistance is defined as censorship resistance. I'll ignore the censorship resistance, as it doesn't seem to have any qualities different from any other Ethereum contract.

I don't see what this project is resilient against. In fact is seems unable to recover from issues such as the trusted third party publishing early.

How is key confidentiality preserved? The integrity of the keys? What if the keys are changed or deleted? How are DOSes protected against, so early disclosures don't get forced?

There are quite a few issues with the project. Unfortunately, killcord doesn't seem ready for release into prime-time as a key-management method. Killcord seems equivalent in intended operation to a non-blockchain HSM, but all the protections of an HSM, all the key management, all the security controls, they are all gone. This actually introduces security issues instead of solving for them.

What is the actual problem that killcord is attempting to solve? There are likely more robust designs, such as secret sharing, that will solve the target problem.

Re: A censorship resistant deadman's switch

#37

Post by XR0CSWV3h3kZWg »

danShumway wrote: post #34
XR0CSWV3h3kZWg wrote: post #32

There is a lot of hate for the trusted party set up of this, which seems reasonable. It seems like you could create a dead man's switch using arbitrary participants. You distribute a secret to every participant and then to attempt to activate the dead man's switch they raise k to the power s mod p and pass it to the next participant. As long as you act as a participant each time and raise the passed value to some inv…

So, sort of like a secret generating linked list, where one node (you) are a bad actor? What prevents the participant right before you from simply circumventing you or secretly passing to the next participant directly? It also seems that once someone receives the correct answer for their step in the chain, they no longer need anyone beneath them? (A) -> (B) -> (C) -> (you) -> (D) Once C has participated in this one t…

Good point. You'd likely want to also encode something that opaque to who exactly has participated, only really show whether this is the last step and a way for individuals to tell if they have already added their secret.

The really bad part would be that if the poisoner happens to be the last step then the final step would produce the secret before handing it to be poisoned.

Re: A censorship resistant deadman's switch

#38

Post by girvo »

XR0CSWV3h3kZWg wrote: post #37
danShumway wrote: post #34

Earlier quoted context omitted.

So, sort of like a secret generating linked list, where one node (you) are a bad actor? What prevents the participant right before you from simply circumventing you or secretly passing to the next participant directly? It also seems that once someone receives the correct answer for their step in the chain, they no longer need anyone beneath them? (A) -> (B) -> (C) -> (you) -> (D) Once C has participated in this one t…

Good point. You'd likely want to also encode something that opaque to who exactly has participated, only really show whether this is the last step and a way for individuals to tell if they have already added their secret. The really bad part would be that if the poisoner happens to be the last step then the final step would produce the secret before handing it to be poisoned.

I built exactly what you’ve described, using semi-homomorphic encryption (addition of integers, used plainly as we were under the noise threshold of participants). Luckily for me though, I got to punt on some of the really hard questions of trust — the nodes that were communicating are adversarial, but the outside “organising” network was the government and “us” (company I worked for). It’s a really fun problem. I highly recommend taking a crack at it, or even just reading the literature regarding digital voting — you need to prove that one vote was cast for a given person, and no more, without ever tying back any specific vote to said person, and with a huge range of attack vectors!

Re: A censorship resistant deadman's switch

#40

Post by XR0CSWV3h3kZWg »

girvo wrote: post #38
XR0CSWV3h3kZWg wrote: post #37

Earlier quoted context omitted.

Good point. You'd likely want to also encode something that opaque to who exactly has participated, only really show whether this is the last step and a way for individuals to tell if they have already added their secret. The really bad part would be that if the poisoner happens to be the last step then the final step would produce the secret before handing it to be poisoned.

I built exactly what you’ve described, using semi-homomorphic encryption (addition of integers, used plainly as we were under the noise threshold of participants). Luckily for me though, I got to punt on some of the really hard questions of trust — the nodes that were communicating are adversarial, but the outside “organising” network was the government and “us” (company I worked for). It’s a really fun problem. I hi…

Neat! Thanks for sharing.
Post reply on HN