Digital Tontine
This originally came from a USENET posting in Sci.Crypt where someone asked about using crypto to communicate from beyond the grave. This is my responseI also am not entirely certian how the method you propose ties in with your death. However, you can find many, many good encryption algorithms in various publications such as Scheier's Applied Crypto, Menenzes, et al. Handbook of Applied Crypto, or Stinson's Crypto:Theory & Practice. With regards to the 'death' part, you may want to check out http://www.deathswitch.com/ . They appear to be offering a service that emails various people upon your 'death', with your 'death' being defined as when you stop going to thier web site to reset a counter. Not completely like the watchdog timer on a number of embedded computer systems.
I don't think they're operational at this point, but my guess is that they will be soon. One thing you may want to consider doing is selecting a random key, write some messages to be sent to people upon your 'death', encrypt the messages with the random key, deliver the encrypted messages to the people on your list. Then, setup something with deathswitch.com so that the random key is delivered after your 'death.' They use the key to decrypt the message, and viola! messages from beyond the 'grave.'
The obvious problem with this technique is that a) deathswitch requires that you login to thier service one every-so-often to reset the 'death counter,' and let's say that you're in a coma for couple of years and can't login. Well, deathswitch isn't precisely perfect in this case. b) You have to trust the guys at deathswitch not to blab your key. c) assuming that you want to live another 50 years or so, you have to select email addresses for recipients that won't change over that period as well as an encryption algorithm and key length that won't be easily defeatable for that 50 year period. d) there's no authentication to prove that the 'message from beyond the grave' really came from you, so some mischevious adversary could fake your 'death.'
So... Addressing points b, c, & d, you may want to add a few things to the message:
1) Encrypt the key you give to deathswitch with another key that you give only to the message recipients. In theory, assuming that deathswitch does not operate a worldwide network of spies and informers, you should be able to keep the message encryption key secret from deathswitch.com. Of course, this doesn't protect from collusion between your message recipients and the operators of deathswitch.com.
2) Add some authenticating information to the encrypted message and the encrypted key. I think that you could generate a public/private key pair, sign the message to be encrypted, sign the key that's encrypting the message, and then destroy the private key. In this case, it might be enough just to know that the same person signed the original message and the message encrypting key. Leaving the private key around is just an invitation for someone to steal your laptop/smartcard/whatever to recover the key.
3) Depending on the people on your message recipient list, you may want to do something fun like use a key sharing or splitting technique that requires multiple people on the list to still be alive to reconstruct the message encryption key.
4) as for key lengths, I think that a 'back of the envelope' calculation we made at Uptronics indicated that we believed that an 88 bit key would be sufficient for the next 20 years, I think I heard recently a recommendation for a 90 bit key (for symmetric algorithms with work factors similiar to DES.) Assuming that Moore's law holds for years 21-50, maybe a 110 bit key. Awe heck, just use RC5 or whatever the AES winner turns out to really be with a 256 bit key and crank your PGP asymmetric key generator up to 4096 bits. Still, keep in mind that advances in mathematics and computing technologies that will occur in the next 50 years may not be forseeable from our current vantage point.
No doubt others in this list may have more issues with this solution. It does, however, introduce an interesting problem. Assume that you want to setup a digital Tontine. A tontine being a traditional arrangement between a group of individuals that some common property should be bequeathed to the last living member of the group. (http://www.lectlaw.com/def2/t094.htm) I am led to believe from watching episodes of M*A*S*H that they were wildly popular amongst American Cavalry officers during the first world war. Using something like deathswitch, a digital tontine can be easily constructed. I'm using the term 'digital tontine' to mean a system where some digital information is delivered to the last 'living' member of a group; the digital information can be anything, I suppose, the key to decrypt the instructions for removing $10,000,000 from a numbered swiss bank account, a digital coin, a tasteless jpeg, it doesn't matter. Also, 'living' can be interpreted in many different ways. Let's suppose you want some critical information (like the password to the firewall configuration utility) to be delivered to the last member of your IT staff that hasn't moved on to work at a small starup in silicon valley.
1) Select the 'Message' to be delivered to the last living member.
2) Generate a public/private key pair. Sign the Message with the private key.
3) Generate a random 'Message Encryption Key' (MEK), encrypt the message with the MEK.
4) Publish the encrypted message from step 1 and the public key from step 2 to the members of the tontine.
5) Split the MEK using some key splitting technique like BBS using N+1 shares where 'N' is the number of members of the tontine. Sign each of the shares with the private key generated in step 2.
6) Destroy the private key from step 2.
7) Email share # N+1 to each of the members of the tontine.
8) For each member 'i' in the tontine (from 1 to N):
a) Email share # i to member # i
b) Member 'i' sends his signed share to deathswitch.com, specifying that each member of the tontine should recieve his/her share upon his/her death.
9) Wait for members of the tontine to start dropping like flies.
Obviously, this assumes that members of the tontine are trustworthy. The public key from step 2 can be used to ensure that the message and shares recieved from deathswitch.com are authentic. Using N+1 key shares (instead of N shares) ensures that the operators of deathswitch.com can't combine the 'N' shares to reconstruct the MEK, of course some subset of the tontine members might still bribe deathswitch.com to reveal all the key shares. Also, you might want to come up with a program that can submit things to deathswitch.com on each of the tontine members behalfs if you don't trust them to do it correctly.
Has anyone else done any work on this? A simple search on 'digital-tontine' resulted in no hits on google.com or alta-vista. If not, this might be a fun (if morbid) subject for an undergraduate, graduate, or amateur research project. If I may suggest topics for further research:
1) Message Recovery. Under which circumstances should the message or message encryption key be recovered (other than the death of N-1 members of the tontine.
2) Application. There might be some application of this technique to selective revelation of secrets to the last member of a corporation employed by that corporation. Ask your boss if this is something they would support.
3) Adding new members. In the 'last man employeed' situation described above, you might want to add new members to the tontine as you hire replacements as single people leave the company. The digital tontine may only be of serious use in the event that all but one member of a tontine leave the company without passing on critical information.
4) Securing yourself from deathswitch.com. Of course deathswitch.com has only your best interests at heart, but let's assume that thier management is replaced by CIA operatives, communists, aliens, or attendees of the Financial Crypto conference. How could you protect yourself (and your tontine) from collusion of some subset of tontine members with the newly compromised management at deathswitch.com? Key Encryption Keys?
5) Patent protection. Assuming that this idea is novel, is disclosing on this newsgroup sufficient to prevent someone from filing for a patent on this later, or should I try to write this up and get it published in a 'normal' journal?
Also, my name's not attached to any algorithm or technique, and it's always been a goal of mine, so if you think this technique has any merit and assuming it's actually novel, I'd appreciate it if you would refer to this technique as "Hamrick's Boneheaded Deathswitch Digital Tontine."
