I'm a little unclear on what problem you're trying to solve. Are you saying you should wait for a second place to set up such a service, sign up for both, and use a simple secret sharing scheme[1] to ensure that only once both go out does anyone know the original message? Or does that not solve the problem you were talking about?
[1]Which in this case would probably just be -- since in this case you don't want it to be reconstructible without all the pieces, and there's not much need for there to be more than 2 -- picking a random string of bits, sending that to one and the XOR with the original to the other.
Here's how it would work:
You decide how many different friends and family you are going to send your secret message to, and how many of them will need to agree to unlock the message together. Let's say you pick 15 recipients and 8 need to agree. Then ANY 8 of the 15 messages can be combined to decrypt the secret.
No 3rd party service needed at all.
Couldn't you encrypt the results again with different numbers? So you could do interesting things like 'my wife AND (any 3 of 50 others)'
Works for this simple case, but I think iterating the procedure is more general. For instance, suppose there are 6 people -- A1, A2, A3, B1, B2, B3, and you want it to be recoverable given any 2 of the A group and any 2 of the B group; I'm pretty sure that can't be handled with a solution like the above.
Simplest would just be to have the 3-of-50 decrypt to another encrypted file, and give the wife the passphrase to that. Nobody holds multiple keys, satisfies the 'AND', and is simple.
> I'm a little unclear on what problem you're trying to solve.
So am I, actually, sorry. My initial thought was that a central authority (a host that might go down or bankrupt) could be avoided if I were to split my secret into parts, distribute them among my loved ones (telling them what it is about and that I trust them they'll not meet behind my back while I'm still alive), accompanied by instructions how it works. This way, there's no plain text of my super secret stored anywhere.
This solves the "my secret should be known by my peers when _something happens_"-issue. The "inform the others if something happens to me"-problem actually persists and for _this_ problem, a service like the one posted probably is a solution, sending out "the person has not been reachable for X days, please meet and uncover his secret"-mails to the peers.
You could setup a scheme where just X (but no less) out of all Y (partial) secret holders are enough to recover the secret. There are cryptographic schemes for that.
Simple way might be to just use overrepresented[1] error correction code like Reed-Solomon where it'd only take half the parties to reconstruct the full message. Should be fairly easy to set up using par2 utilities right now actually.
[1] I'm fairly certain there's a real word for this, but I cannot think of it, anyone else know?
Assuming the number of parties is fixed (and it would have to be, wouldn't it? I don't see how the question could make sense otherwise), this is still more complicated than necessary. The general term for this is "secret sharing" and there's a really simple method for it, known as Shamir's Secret Sharing.
Sounds like what Tahoe-Lafs does - uses the ZFEC (another FEC algorithm, like Reed-Solomon, but much faster) library to let you specify how much redundancy to generate; you can have 2-out-of-3 or 3-out-of-9 or other ratios.
[1]Which in this case would probably just be -- since in this case you don't want it to be reconstructible without all the pieces, and there's not much need for there to be more than 2 -- picking a random string of bits, sending that to one and the XOR with the original to the other.