As far as I can tell, Ethereum isn't actually doing anything interesting here - it's just being used to transmit pings to the server, which could just as easily be done with, for example, tcp/ip.
A censorship resistant deadman's switch
61–69 of 69 posts
Re: A censorship resistant deadman's switch
#62Earlier 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.
You can achieve the same with tor hidden service.
Re: A censorship resistant deadman's switch
#63[deleted]
Re: A censorship resistant deadman's switch
#64This 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 treats ethereum as a project backend API. The smart contract is pretty simple in construction by design. Writes are restricted to one of two accounts (the owner account and the publisher account) and the publisher account is further restricted to only allow writes to the publishedKey variable in the contract. Reads are open to the public. As stated in other responses, the decryption key is stored own trusted…
This helped a lot!
Re: A censorship resistant deadman's switch
#65Earlier quoted context omitted.
That just lets you see the contract. The decryption keys by necessity can't be located on the Etherium chain at all and have to be held by a trusted 3rd party/system that watches the contract and releases the keys when the checkin doesn't happen. If the attacker is able to locate and disable that system then the killcord is essentially diffused the owner would have to manually publish or have setup backups.
Right. The decryption keys aren't on the blockchain until they are "published". If all publishers are compromised or shut off before that happens, the killcord project has been terminated.
Yeah, though finding them should be fairly hard because all they will look like from a network traffic perspective should be a normal-ish etherium non mining node and no direct communication between owner and publisher should exist after initial setup. Anyone planning on using this for serious matters should make sure that their trusted publishers are hosted anonymously (as far as is possible) or so spread out jurisdictionally to make attacking them all impractical.
Re: A censorship resistant deadman's switch
#66This 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 treats ethereum as a project backend API. The smart contract is pretty simple in construction by design. Writes are restricted to one of two accounts (the owner account and the publisher account) and the publisher account is further restricted to only allow writes to the publishedKey variable in the contract. Reads are open to the public. As stated in other responses, the decryption key is stored own trusted…
Amazing, thank you!
Re: A censorship resistant deadman's switch
#67This 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 treats ethereum as a project backend API. The smart contract is pretty simple in construction by design. Writes are restricted to one of two accounts (the owner account and the publisher account) and the publisher account is further restricted to only allow writes to the publishedKey variable in the contract. Reads are open to the public. As stated in other responses, the decryption key is stored own trusted…
Are you using only a single decryption key?
If so, you could switch into M of N scheme - far more secure, and thanks to Ethereum, the coordination between key keepers would be really simple.
(Kind of what we did with Orisi.org years ago)
Re: A censorship resistant deadman's switch
#68if someone puts a gun and steals your private key he can continue checking in after he kills you right?
Yes. In the current form, If someone gets the project owner config file they could continue to check-in indefinitely. I've been toying with the idea of optionally encrypted the owner config with a passphrase to mitigate this. It would even be possible to have a secondary "duress password" that pretends to decrypt the config, but publishes instead.
but it should give the attacker confirmation that all is ok and somehow the attacker can't know that it was published?
Re: A censorship resistant deadman's switch
#69Earlier 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…
Was this a traceable ring signature[1], or something different?
[1] https://en.wikipedia.org/wiki/Ring_signature#Applications_an...