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 in Etherium, and Etherium is only being used as the consent to publish?
If the key is being stored somewhere else and just waiting for the contract to validate, how do we prevent a censor from just attacking that system?
If the key is being stored somewhere else and just waiting for the contract to validate, why not also store the contract on the same machine and do checkins directly into that? Would that be significantly less secure/reliable?
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?
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.
Killcord is designed to let the public know that a killcord project exists, where to find the encrypted payload, and how to check the status of the killcord project.
Unpublished secrets are currently stored on the owner and publisher project folders in clear text on a config file. This isn't meant to replace an HSM or secret manager, by any means. Though I've got some ideas on how to incorporate systems like Vault, Chamber, or other secret stores in the future.
It is also, indeed, early alpha and dealing with secret management for the owner and publisher are absolutely top of mind.
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 the smart contract, visible to everyone.
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 it would still be pretty difficult for anyone to censor you.
It also seems like a party that wanted to force you to publish early would not be hampered in any significant way by Etherium. In either scenario, all they have to do is incapacitate you or block the IPs that your machine is looking at.
I still feel like I'm missing something. Would anyone be willing to break down a (fictional or real) scenario where adding Etherium to this equation blocks an attack?
You can encrypt an entire circuit with homomorphic encryption, which users can run without decrypting its internal state. Construct a device like so:
Inputs: 1. Ethereum block 2. Previous run-state (encrypted) or zeros.
Outputs: 1. Next run-state (encrypted) 2. Decryption key (if triggered) or zeros (if not.)
Internal state: 0. Hash difficulty range 1. Hash of previous block seen 2. Pubkey to scan for 3. Counter of # blocks seen without a tx signed by pubkey.
If you feed the device more than 1 week of blocks without a tx from pubkey, the accumulator hits zero and it spits out the secret.
An attacker would have to mine 1 week of blocks at hash power IS.0 in order to trick the device into spilling its guts. If you die, and don't send txs for a week, anyone with the device can play a week of blocks into it and the secret will pop out.
Unfortunately, homomorphic encryption is still too slow for this to be quite feasible. Food for thought though! And you can build this today with SGX, if you trust that.
I'm working with a friend who is a copy writer to help make the landing page clearer and more helpful.
That being said, I'm working on the concept of "providers" so that storage, payload, and backend can be plugable and you'll be able to use whatever backend you are comfortable with.
1) The key castodian can decrypt your Information either willingly or through coercion. If you use the same key to sign and encrypt the message or if you do not sign it then they may also be able to impersonate you.
2) A third party who would gain from the information being disclosed can force its release through a denial attack.
Never use a deadman switch as a bargaining or as an insurance policy if you do not intend the information to be released to the public and if you are not comfortable with the information being released the moment the switch is set up rather than when it would be activated.
The only manner in which this or any simmilar setup does not expose you to additional risk is if you only use it to ensure the release of said information in a timely manner and there is no adversarial motive to release it sooner.
@the creators you might want to look at the possibility of implementing https://en.m.wikipedia.org/wiki/Chaffing_and_winnowing over a blockchain.
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.
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?
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.
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.
I get the premise, where typically it's illegal to take an action that releases confidential or censored information.
But, to governments, especially ones that want to keep information secret or censored, I'm not sure that negating that sequence and failing to stop the release of information (that you willingly put in a dead man's switch) will get you out of trouble.
Unless you're dead of course. But, I've seen this process promoted for living people to release information and I'm not sure it's any better than just posting the content anonymously, but with the added risk of accidentally releasing the information.
When the transactions stop, people know you are dead.
This way you need no trusted third party, no special software, no special contract.
Suppose you're a whistleblower, who exfiltrated gigabytes of unredacted data from the NSA. So far you've leaked only redacted excerpts, but the NSA might kill you to stop your leaking.
However, the NSA really doesn't want the whole archive leaked, or it would blow their agents' covers.
So, you put the whole archive up on the net, encrypted, and set up Killcord to decrypt unless you keep checking in. This keeps you alive, since the NSA knows it'll leak if you're dead.
I am in the early stages of building a "providers" abstraction for killcord so that backend, publisher, etc are plugable. Using this bitcoin pattern for check-ins could be really cool.
The way around this is to threaten not to kill the target, but rather kill their whole family or those they care about viciously and painfully, and be ready to do it, if the order is wrong and there is an automated leak.
I always find these arguments against coercion attacks unconvincing. "Well, they can force you to give them information A, but for some reason not force you to give them information B." No, they'll put you in jail and force you to give them all the information needed to send check-ins, period.
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.
