[Dylan16807]

While it's a clever method, it's also worth noting that for moderately-sized groups you can achieve the same thing with a much simpler method and almost no math.

Let's say you have a 256 bit key as the secret, and you want any 5 out of 15 people to have access.

For each combination of 5 people, pick 4 random 256 bit numbers. 4 people get those and 1 gets the key encrypted with those numbers as a one time pad.

Once you do every combination, each person will end up with a list of a thousand numbers. Any 5 of them can get together, each grab their number for that group, and XOR them to access the secret.

That's only 32KB of data to hang onto. With 15 people the absolute max is 107KB. Even printed as plain text it would need less than 20 sheets of paper.

[DennisP]

Oh that's great. At one point I wanted to use SSS just for two out of three. I can't believe it never occurred to me to just say "if you're pairing with Jack, xor his number with this one." It's even simple enough to do by hand.

[StavrosK]

What happens if 5 people who have encrypted random numbers (and no key) get together?

[Dylan16807]

What's an "encrypted random number"?

If they have 5 random numbers and XOR them together, then they won't get the key as output.

[StavrosK]

So then it's not "any" 5 out of 15, it's "any group of these three", which is a significant disadvantage compared to SSS.

[dmurray]

No, it's any 5 of the 15. You do the procedure for each of the 15c5 = 3003 groups of 5.

Each person is part of 1001 groups and has a separate 256-bit number for each group. To recombine the numbers, each of the 5 needs to select the number corresponding to that group.

I think this works just as well as SSS for small/moderate sized groups. It's a little less elegant because you need to know which group you're participating in at decode-time, and because it's not scalable (but there are few serious applications that need the scalability).