FROST is one example of such a threshold scheme, for computing Schnorr signatures: https://eprint.iacr.org/2020/852.pdf
[1] https://en.wikipedia.org/wiki/Distributed_key_generation
One example is as follows: each party i generates a random polynomial P_i, and n secret shares of that polynomial (j, P_i(j)) for j in 1..n
Then, party i sends (j, P_i(j)) to party j. Party i similarly receives shares (i, P_j(i)) for j=1..n. Party i stores the share (i, sum(P_j(i))).
Then, parties reveal their shares as usual, the secret is then the sum_i P_i(0).
Of course, if the parties are dishonest, you might want some additional safety mechanisms, which can be dealt with with Kate commitments.
This papers https://eprint.iacr.org/2020/504.pdf goes into details, and much more.
Splitting the key safely is only part of the problem though, because you will then need a system that only -uses- the key in a way all parties consent to.
Threshold signing is a much easier alternative for many use cases but sometimes a cryptosystem requires just one key and SSSS is all we can do.
To avoid any single party accessing a complete SSSS split key you can:
1. Write an application that takes N public keys as input, and returns a newly generated key as SSSS shares encrypted to each respective public key as output.
2. Compile application deterministically as an immutable unikernel or firmware image targeting hardware that supports remote attestation (Nitro Enclave, Confidential VM, HSM, etc).
3. Publish source code such that all participants can access and review it, or confirm review was done by multiple parties they trust.
4. Have multiple parties trusted by all participants, or the participants themselves, build the application bundle and confirm they get the same hash
5. Any party deploys the bundle to a live remotely attestable system.
6. All parties use the remote attestation interface to confirm the target system is running the multi-party deterministically compiled application they expect.
7. All parties submit their public keys to the remote system.
8. The remote system generates new key, splits it, and returns SSSS shares to each party encrypted to their respective public key.
What you describe still trusts the distributor - you just found a way to make the distributor easy to trust. I'd be more interested in a mechanism that is mathematically correct, like some of the papers referenced elsewhere in this thread.
There is no avoiding standing up computers all parties trust and if you are going to do that anyway then you might as well use them for key generation and distribution too.
I mean, if we all agreed to perform the decryption, the secret's out anyway. But not before then.
The real world use cases I most commonly support are things like CAs, TLS keys, financial transaction signing keys, and sensitive document decryption keys. All of these require single keys to exist that needs to perform automated operations, and needs to be on systems that can be backed up, restored, upgraded, and maintained, while able to prove no single person can access or control the keys.
The scheme I described can allow one key to be created, split, restored, used, and split again many times without full trust in any individual.
You usually have a ring of people and need 3 out of the 7 to open the box. You simply encrypt the box in whatever combinations you want, and people run their keys against each layer of the box. You end up with a few different files but in the case of keys, and a small number of sharers this is not going to be a big data issue.