We recently added an article about the “dead man’s switch” to our solutions series–https://blog.enigma.co/tell-no-tales-decentralizing-a-dead-mans-switch-6217e2f4361b
Simplified diagram of DMS components in an Enigma implementation
A dead-man’s switch on Enigma would have a secret contract , which is used to store the secret information. A contract on Ethereum would function as the proof of life /check-in, and would have incentivize “time-keepers” to monitor that the user continues to check-in. The “secret contract” can replace both the publisher and the revealers in the previous two models. Time-Keepers, unlike revealers, do not have the option to collude off-chain as they never have access to the decryption secret. Additionally, the secret contract enables straightforward private recipients.
Simple threat model for DMS:
One possible data flow would be:
Initiation
-
User encrypts all inputs to the secret contract using Enigma.js library: their message, the recipient, the desired check-in interval.
-
User submits encrypted inputs to the secret contract on Enigma, and submits a hashed copy of these inputs to the Enigma Contract on Ethereum (and creating a Task Record for this contract).
Time-Keeping
-
The user funds a new Ethereum contract, the “time-keeping contract” and then passes proof of that signed transaction to the DMS secret contract Enigma network. The user must repeat this within the specified interval: submitting a transaction to this contract, and then submitting a proof of this transaction to the secret contract on Enigma. This functions as the “check-in”, with timekeeping established by block.time. Similar to Kimono, this game incentivizes time-keepers to periodically sign the block-time and submit this data to the secret contract on Enigma.
-
User ceases to check in within the specified interval. Any other user is able to submit a signed transaction block-time to the secret contract. When the elapsed time is greater than the interval specified by the user, the time-keeper receives the reward and the message within the secret contract is able to be released.
Message Release
- If private recipient is specified, that user may submit her public encryption key to the secret contract and receive the message exclusively.
In the described scenario, the time-keepers lose the ability to collude off-chain, as none have a share of the secret message. The time-keepers may not be necessary if the intended recipient knows about the contract and is incentivized herself to check it (i.e., in a trust). The time-keeping game should be customized around the specifics of the application. Another variation is to use the secret contract as part of the secret-sharing scheme. This implementation for key-management has already been explored in academia — see paralysis proofs. Enigma provides the infrastructure for solutions such as these — the proposed data flow is only a starting example, and we look forward to feedback and improvements on this scheme.
To recap, the interesting contributions a DMS built with Enigma adds are:
Private Disclosures
Unlike both examples, Enigma enables the payload to be encrypted for an individual or group of recipients rather than the entire world. By submitting the address of the intended recipient to the secret contract, when the time comes for the secret to be disclosed, the recipient can submit their public key to the secret contract and receive the secret that only they can decrypt. This is relevant for scenarios where specific people are the desired recipient of the secret, rather than the public. With Enigma, information about whether a secret has been exposed, how frequently the user checks-in, and the address of the private recipient are all encrypted inputs to the secret contract. This improves overall privacy, because not only is the secret information private, but the metadata associated with this mechanism is also private.
Reducing trusted parties
The “publisher” on Kill Cord as well as the “revealers” on Kimono both provide attack surfaces for a counterparty. Recall the two attack vectors of false positives and false negatives . In Kill Cord, compromising the publisher could give an attacker early access to the decryption key. Attacking the user’s connection to the publisher could also prevent the publisher from publishing the key to the smart contract. Kimono relies on staking incentives to prevent collusion amongst revealers, an approach which is insufficient if the reward for collusion is very high (say, the private key to an exchange or high-balance wallet!)
Complex Conditional Disclosure
Enigma enables private inputs for both the creator of the switch and the intended recipient. Imagine a switch conditional on some other criteria being fulfilled, aside from the user’s apparent demise — for example, allow Alice to access this material, but only if she is accessing it from within a certain region. Or, perhaps to anyone accessing material from within a certain region, like a scavenger hunt. Additionally, the switch can set up to be triggered by more than simple inaction or failure to check-in. Thus, the DMS model can be extrapolated beyond wills, insurance, and trusts, and could also potentially be used in advertising, gaming, or other situations.
Thoughts? Particularly curious about methods for incentivizing the time-keepers in a way that prevents a sybil attack (possibly an interval-based reward? This would also prevent the receipt of an award “proving” that the dead man switch had flipped. Instead of rewarding whoever is first to check after the interval has passed, a la KImono, there is a monthly/yearly/whatever reward (loaded by the initial owner for however long they believe the system should run) to whoever is first to “submit time” in that interval.
