41–50 of 69 posts
When the transactions stop, people know you are dead.
This way you need no trusted third party, no special software, no special contract.
Better and simpler solution: Create a Bitcoin address and send one Satoshi to yourself every month. 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.
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…
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?
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…
As for the second attack vector, the publisher is built with idempotence, so it is important that a killcord owner configures n-number of publishers in geographically diverse areas to mitigate the false negative attack vector.
Hey Gang. Author of killcord here. I'm honored and humbled this was submitted to HN and I'll be reading through the comments to answer questions and respond to feedback. I started this project after a thought experiment in using newer decentralized tech for internet activism.
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.
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 c…
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.
Censorship resistant, until someone takes down the “publisher tool meant to run autonomously on a trusted system”.
Better and simpler solution: Create a Bitcoin address and send one Satoshi to yourself every month. When the transactions stop, people know you are dead. This way you need no trusted third party, no special software, no special contract.
You're describing a different problem. Killcord solves the Insurance Policy problem: 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, enc…
Does this take into account network congestion and such?