Live data from Hacker News

Ssss: Shamir's Secret Sharing Scheme (2006)

point-at-infinity.org

31–40 of 51 posts

Re: Ssss: Shamir's Secret Sharing Scheme (2006)

#31
post #18

This is a wonderfully simple scheme to split up keys between parties, but this still involves a party (the one that made the key) at some point knowing the key. This scheme implies you trust this distributor not to make copies of the key for himself (queue sauron references...). I've wondered if there's a scheme that does NOT trust the distributor of the key. What if the only time they key was known was when the part…

I build systems designed to distrust any single individual with cryptographic key material and SSSS needs a lot of careful handling and automation to accomplish this.

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.

Re: Ssss: Shamir's Secret Sharing Scheme (2006)

#32

Earlier quoted context omitted.

Plenty. Look into publicly verifiable secret sharing. https://en.wikipedia.org/wiki/Publicly_Verifiable_Secret_Sha...

That doesn't seem to answer the question - the schemes on your link still have a dealer with access to the original secret I think? Is it possible to have each participant contribute an input that forms part of the original secret, such that they get combined to form the secret and then split into shares in a way that doesn't require a dealer?

See my other comment in this thread which details a solution to this.

Re: Ssss: Shamir's Secret Sharing Scheme (2006)

#34
post #31
post #18

This is a wonderfully simple scheme to split up keys between parties, but this still involves a party (the one that made the key) at some point knowing the key. This scheme implies you trust this distributor not to make copies of the key for himself (queue sauron references...). I've wondered if there's a scheme that does NOT trust the distributor of the key. What if the only time they key was known was when the part…

I build systems designed to distrust any single individual with cryptographic key material and SSSS needs a lot of careful handling and automation to accomplish this. 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 req…

> This scheme implies you trust this distributor not to make copies of the key for himself (queue sauron references...). I've wondered if there's a scheme that does NOT trust the distributor of the 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.

Re: Ssss: Shamir's Secret Sharing Scheme (2006)

#36
post #27
post #17

Earlier quoted context omitted.

iiuc HN flags new accounts by creation time and not activity (e.g. less than N days old)

iiuc it's by activity. The user isn't green because they've posted the link several times, just never stuck around to comment. This is a one-way relationship, users like these detract from the conversation, they have one thing to say only and every time it only benefits them. Downvote me for being a jerk, I don't care, I'm not wrong. They probably don't mean any harm, and maybe aren't free to speak in a job context o…

This discussion seems valuable, no? How would we be having it if not for this user’s contribution? Who’s using whom, now?

In any event, the only person detracting from this interesting thread on SSS, is you.

Re: Ssss: Shamir's Secret Sharing Scheme (2006)

#37
post #18

This is a wonderfully simple scheme to split up keys between parties, but this still involves a party (the one that made the key) at some point knowing the key. This scheme implies you trust this distributor not to make copies of the key for himself (queue sauron references...). I've wondered if there's a scheme that does NOT trust the distributor of the key. What if the only time they key was known was when the part…

I have done this with other parties by brute force for crypto.

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.

Re: Ssss: Shamir's Secret Sharing Scheme (2006)

#40
post #31

Earlier quoted context omitted.

I build systems designed to distrust any single individual with cryptographic key material and SSSS needs a lot of careful handling and automation to accomplish this. 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 req…

> This scheme implies you trust this distributor not to make copies of the key for himself (queue sauron references...). I've wondered if there's a scheme that does NOT trust the distributor of the 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 els…

Even if you avoid trusting the distributor, the quorum of share holders still will end up having to reconstitute the shared key into the memory of a computer somewhere at some point to do cryptographic operations with it.

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.

Post reply on HN