One other thing that is really cool about secret sharing, is that you can actually perform computations (addition, multiplication) on secret-shared numbers. This way you can actually perform arbitrary calculations "in the encrypted domain", in a way that is currently a lot more practical than fully homomorphic encryption.
You could extend the decoding procedure to tolerate errors. Shamir's secret sharing is the same thing as Reed-Solomon code, so you can reuse the error-correctimg property of the latter.
> Eleven scientists are working on a secret project. They wish to lock
up the documents in a cabinet so that the cabinet can be opened if
and only if six or more of the scientists are present. What is the
smallest number of locks needed? What is the smallest number of
keys to the locks each scientist must carry?
> 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
It becomes obvious only after making the less than obvious assumption that locks can work in OR fashion rather than the usual AND fashion. How does one put 462 locks on a cabinet such that opening any one lock opens the cabinet?
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.
Does anyone know if secret sharing, or the equivalent, is provided by cloud vendors as a way to secure extremely sensitive high level permissions?
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've been working on something similar to what you described[^1], using Shamir secret sharing to split the TOTP secret. Once enough key holders get together, a server generates some TOTP tokens, but only for a limited period of time.
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.
Thanks, this actually helped give me a good idea about how I would like to do this now:
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.
Yes exactly, that's the idea with that tool, this would make the process compatible with most services (I'd hope, that all services that require this level of attention also offer TOTP).
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.
Understood, I was just hoping that cloud vendors (or associated tools) would implement the "2+ person rule for access" directly within their interfaces.
Dark Crystal (https://darkcrystal.pw/) provides a toolkit (a set of protocols, libraries and reference code) for using Shamir's Secret Sharing within different social fabrics.
Mozilla SOPS, a tool for encrypting secrets for storage in source control systems, lets you encrypt secrets using the Shamir Sharing Threshold. You can use (and mix and match!) keys stored in of the first-party cloud secrets managers (AWS Secrets Manager, GCP KMS, Azure Key Vault), Hashicorp Vault, GnuPG, or Age.
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.
Hashicorp Vault by default makes use of this mechanism to ensure certain actions (most notably starting Vault and unlocking the secret store for use) require multiple users to approve it.
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.
You can read a later publication from my professor here https://www.scitepress.org/Papers/2011/34814/34814.pdf