How to Share a Secret [pdf] (1979)
web.mit.edu
web.mit.edu
You can read a later publication from my professor here https://www.scitepress.org/Papers/2011/34814/34814.pdf
See https://en.wikipedia.org/wiki/Secure_multi-party_computation
> it is not hard to show that the minimal solution uses 462 locks and 252 keys per scientist
Probably obvious to most on HN but the answer didn't jump out at me immediately: 11! / 5!6! = 462
If using a chain, connecting locks in parallel between the links would be AND, and locks in series between the links would be OR.
Cheers
Here's a CLI, written in Go, that uses HashiCorp Vault's implementation of the Shamir Secret Sharing algorithm and exposes its functionality to the command-line in an easy-to-use manner.
I personally use it to divide my password manager's master password into shares that are given to family members and close friends in order for them to collectively reconstruct my master password and obtain access to my password vault in case I pass away.
Disclaimer: I'm the author.
For example, most cloud services have the concept of an "owner" account that has full access to everything in a project. Most security advice I've read says that pretty much nobody should have access to the owner account - the credentials for the account should basically be locked in a vault (but that kinda just pushes the issue to "who has the keys to the vault").
Instead, what I'd like to do is share the owner account password into 4 parts, where any 2 are needed to get access to the owner account. That way no single employee can "go rogue" on their own. Obviously I can share the password by myself using something like SSS, but would be nice if I could just designate a group of n IAM accounts, but where a minimum of k are needed to get full owner privileges. The idea is similar to the "2 keys must be entered at the same time to launch the nukes" idea.
Basically, just curious if other folks share their owner account creds that require some minimum consensus before accessing.
I wanted to use it in an enterprise environment to limit the access to AWS root users in a break-glass scenario. Now I no longer have such need and haven't developed it further, but the core features are there. As usual though with this kind of tools, any security problem becomes a key management problem and it'd need a bit more work to use it in the real world.
1. Generate the password for the owner account, store that in "standard" secrets storage where admins can access it. 2. Also require TOTP MFA for the owner account. Take the seed for the TOTP, and split that into N shares (where N is equal to the number of admins you want to share it out to) requiring K threshold (where K is the minimum number of admins that must come together), and give that out to your admins.
I believe the sensible next step would then be to implement a mobile authenticator app for this protocol, that can scan QR codes, perform the initial "split", send out the shares, and then orchestrate the generation with other players.
The initial step is the weak link: the user could just store that TOTP secret and everything else becomes pointless. It'd be great to have the service itself (e.g. AWS) generate those shares on their end and send them out individually. But then again, a malicious actor with that kind of access to begin with would have a thousand other ways to do some damage.
https://www.vaultproject.io/docs/concepts/seal#shamir-seals
Shamir seals
The default Vault config uses a Shamir seal. Instead of distributing the unseal key as a single key to an operator, Vault uses an algorithm known as Shamir's Secret Sharing to split the key into shards.Various IaC ecosystems have integrations for it. It's probably the best way to store secrets for Nix-based deployments, and there are also docs and integrations that pair it up with Kubernetes and Terraform.
Idk how many companies are really using keygroups, though. Probably in some of them, the repos are public and can tell you that.