Hacker News Reader

Comment by s2r2 | Hacker News Reader

Something similar could be constructed using Shamir's Secret Sharing (for example) [1], where the involved parties would have to communicate (and thus know each other) to retrieve the secret from their parts. The linked service surely is easier to handle but such a scheme would not depend on any trusted host (except yourself as you know the secret and share the parts). Possibly a combination of both would be great, to ease the communication issue and still keep security high.

[1] http://en.wikipedia.org/wiki/Shamir%27s_Secret_Sharing

View on HN

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)'

'my wife AND (3 of 50)'

You could take k=54 and give your wife 51 keys.

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.

I think your right. One (k,n)=(2,3) scheme for each group to unlock the (2,2)-scheme for the secret.

And the wife just needs to remember one key this way...

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.

What happens if your death coincides with the death of one of your secret holders (I.e. you and your mom die in a car accident)?

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?

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.

I'm fairly sure that using this scheme will leak "encrypted" data like crazy. What is your proposed algorithm, exactly?

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.

Reply on news.ycombinator.com