| 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 systems that run the owner or publisher killcord projects. As for attacking the system this is something to think about. So why did I choose Ethereum for this? Why Ethereum - The contract code (backend API) and variable state are written to the block chain, so the availability are dictated by the network itself which is made of around 20K nodes (give or take). Of course, as others have mentioned the other aspect of this is internet access for the publisher and project owner. For the publisher, this can be accommodated by running the publisher in a geographically distributed set of trusted systems. What do I mean by trusted systems? These are systems that meet your risk profile. The code can run on AWS Lambda in multiple regions, or on a raspberry pi, or in a datacenter in iceland, the more, the merrier. For the owner... If you are cut off from checking in, the system assumes something bad is afoot. This is why its important that anything put in killcord is something you really want to publicly disclose. Killcord should really only be a system that runs on your behalf in the case that you go MIA and you feel that is a threat to the data being otherwise released. Hope this helps clear things up a bit? |
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)