[pbaehr]

This is interesting in its own right, but the Assange use case doesn't really make sense to me. Wikileaks doesn't want the encryption to be broken after a certain amount of time, they want it broken based on the condition of assassination.

[arielweisberg]

The primitive for this is a dead man's switch. I wonder what the cryptographic equivalent would be.

Some sort of computational network that will always make progress towards decrypting the data unless the soon to be dead man injects something using his private key that sets the network back preventing completion?

The network can't identify that the soon to be dead man is preventing progress?

Sounds like a fun research project. Maybe tie it to some coin mining network.

[betterunix]

The problem with using a secure protocol is that you need to trust the parties to not just instantiate a second version of the protocol without you. If you can trust them to do that, you can just give them shares of the secret and trust them not to recombine the shares unless you die.

[arielweisberg]

I think what you would do is make it computationally infeasible for them to create a separate network. The network exists independent of your individual secret and may be working towards the release of many soon to be dead men's secrets in a peer to peer fashion.

Sure they could avoid the dead man injecting something, but then they would get hit with the full workload. If you coupled this with an economic incentive like bitcoin mining you could get the miners to allow you to drastically increase the amount of work required and make it keep up with the state of the art in technology.

I couldn't say whether you can string enough primitives together to build something like this but it would be really cool if you could. Maybe I should go file a patent or something :-P

[betterunix]

"I think what you would do is make it computationally infeasible for them to create a separate network."

If the goal of the network is to release my secret when I fail to participate then there must be a way for the network to operate without my participation. What stops the parties from ignoring the messages I send, thus recovering my secret by simply pretending I died?

[arielweisberg]

I think that is one of the novel pieces of functionality that needs to be created. The soon to be dead man looks like any other miner to the network and submits what appears to be valid work, but he is secretly poisoning the work going to release his secret, and of course he has to be the only one capable of doing that. Maybe later on the network realizes the work it was doing was poisoned and rolls back the poison change and resumes processing. Every time a poison pill is introduced the network must do some amount of work to determine that that the pill must be discarded and that amount is tunable by the soon to be dead man.

"What stops the parties from ignoring the messages I send, thus recovering my secret by simply pretending I died?" They would have to control enough of the network and know who you are and how you are interfacing with the network to stop you. If the network has an incentive like bitcoin mining this could be infeasible for many adversaries.

Tampering is a problem with real dead man's switches as well such as a script that you have to ping or an associate.

I think big computational networks with incentives unlock some interesting doors. If you can assume that the computational majority of the network is playing ball you can ask it to do some interesting things if you have the right private key.

[betterunix]

""What stops the parties from ignoring the messages I send, thus recovering my secret by simply pretending I died?" They would have to control enough of the network and know who you are and how you are interfacing with the network to stop you."

OK, but if the assumption is that out of the n parties in the network no more than k parties are malicious, why not just use a k+1 out of n secret sharing scheme? You broadcast a signed message once per month, and if the message does not arrive for some number of months the parties all broadcast their shares and recover the secret.

At best, the role of "proof of work" systems here is in combating sybil attacks, which is only relevant if you want to remove the requirement that I know the people I am issuing shares to. If that is truly advantageous, the system might look like this: first, I broadcast a public key for some non-malleable encryption scheme. Each party willing to participate will then use that key to encrypt a randomly generated ID string that they keep secret. Once I have received the IDs, I broadcast a random string, and each party will use their chosen ID and the random string as a "starting point" in a proof-of-work scheme. The output of the proof of work is then used as the seed to generate a keypair for a symmetric cipher (using an appropriate key derivation function). The parties encrypt the proof-of-work outputs and send the ciphertext to me; I check the proofs and generate the keys locally. Then I encrypt each party's share using the party's symmetric key and send the encrypted share. Then I proceed as before, sending a periodic message.

I suspect, though, that such a construction is overkill; also I have not really evaluated the security of it.

"I think big computational networks with incentives unlock some interesting doors"

Maybe so, but right now I see a solution in search of a problem.

"If you can assume that the computational majority"

Why should I need to assume anything about the computational resources about the participants? We can have threshold secret sharing with unconditional security, and we only need to trust one of the parties for the switch to be secure regardless of the computing power of the rest of the parties.

[simbolit]

Your proposal is no better than the 3 letter server farm working alone. If the poisoner is not inside the wealthy attacker, then the attacker knowing this scheme is better off not cooperating with anyone, including you.

Even if that were not the case, your scheme relies on your identity being a secret, which essentially is "security through obscurity".

We have to assume that a dedicated attacker knows no greater incentive than breaking the encryption. Anything else is foolish, IMHO.

Edit: clarification

[gwern]

I'd argue that Wikileaks doesn't want it released solely on his death but more like 'Assange's assassination or 10 years, whichever comes first', so it does get released eventually.

And I'm surprised no one sees a use-case in recent events: if I were DPR, I'd be happy if usable time-lock crypto existed so I could, say, lock a wallet of 100k btc for 10 years, and give it to a friend as a backup; I don't have to worry about the friend deciding that they'd like to retire to Patagonia, but if I'm 'shot resisting arrest', at least I left my friend a fortune. Or, even if he hands a time-locked wallet over to the FBI, he's delayed them spending it for 10 years and given the Bitcoin economy that much more time to grow and be able to absorb a sudden infusion of 1% of the money supply.

As it is, he's basically in an all-or-nothing position.

[tlrobinson]

I believe your DPR use-case is possible with Bitcoin, using "lock time" contracts. https://en.bitcoin.it/wiki/Contracts

Every transaction can have a lock time associated with it. This allows the transaction to be pending and replaceable until an agreed-upon future time, specified either as a block index or as a timestamp (the same field is used for both, but values less than 500 million are interpreted as a block index). If a transaction's lock time has been reached, we say it is final.

[gwern]

Yes, the specific case of a fallback is possible, but not the general time-lock case. I think. I was discussing this a little with the Bitcoin developer mentioned there, Mike Hearn, but I quickly got out of my depth and the conversation petered out.