For "everyday" practical use, there is also a really simple command line utility around called `ssss` which is available in many distro repos[1]. Debian has it since Jessie[2] and Ubuntu since around 12.04.
I think that ssss was written to operate on passwords and its implementation is based on the original paper and so reasonably does not employ the more efficient implementation means.
Probably the best fast way to get an intuition for this is to realize that Shamir Secret Sharing is literally a generalization of the One Time Pad to support N of M threshold security and so it shares in common much of the same "theoretically perfect", "insecure in practice", and "highly appealing to people who don't know better" properties.
Of course, there are places to use it-- especially embedded inside other systems-- but unfortunately most of the interest comes from places where it doesn't make sense and this reality is reflected in the software.
your link brings up an excellent point about multisig being a much better option for guarding cryptocurrency (because the shards don't need to be brought together on a single device.)
but sometimes you just have to write down passwords. you can use a password manager, but then you need to guard the master password. you can use a TPM with a PIN, but what if you lose the PIN or get hit by a bus or the TPM gets fried?
so either you write down the whole password in at least one place, or you write down shards. shards seem safer.
I’m usually pretty wary of heavily opinionated wiki essays. “It’s not often implemented properly” with two examples of how it’s failed while ignoring all the correct deployments seems pretty skewed. The essay even concludes that SSS used in higher order group-share protocols is fine because there’s a “high bar for correctness”. You can probably sum up the entire rant as “don't roll your own crypto” and “use the right tool for the job”.
All the fault information there is in software people would have gone and downloaded instead of "rolling their own".
It's not like cryptography software is magical gift from the gods, someone wrote it.
And often the people writing SSS software do not do a good job, partially because the properties that SSS by itself provides are not very useful and if they were thinking carefully they wouldn't write it at all.
This argument is not unique to SSS, is the point I think we clearly agree on. Good software is hard. Find a good implementation of SSS or take the time to do it properly. I agree, it’s not magic.
It’s not particularly damning, either. He seems to outline characteristics of a solid SSS design which, in my experience, are exhibited by popular implementations these days.
One idea this inspired me with is to create a single html file which contains both the code to assemble a SSS secret (from other HTML files or the base64 encoded secrets). The key thing that I think would help SSS work is to bundle both the secret part and the code to decode it in combination with the other parts. Said code should also be easy to run for the foreseeable future which is why HTML and JavaScript is a good choice.
I've been trying to come up with a good way to give my loved ones access to my KeePass vault in case I am incapacitated/dead. ssss for the password isn't great because I don't want something complicated and error prone.
My usual method for syncing my vault is to use Google Drive and this method would work well with this since I can just give said family members access to the encrypted vault but send the keys individually. Since I don't rotate the password on this vault, these partial keys only need to be sent once.
I don't need anything too complicated. I just need to be able to set it up such that any two of my trusted love ones can access this vault in an emergency.
Hi, OP here. I made this little tool in a few hours to play with SSS, for an upcoming interactive article on end-to-end encryption. It uses the @stablelib/tss NPM package to do the heavy lifting. The UI is made with ChakraUI [1] & Next.js [1], source on GitHub [2].
This implementation is flawed. Each shard gets a unique substitution cipher making this nothing more than a cryptogram generator. Input "aaaaabbbbbcccccdddddeeeee" with any number of shards/threshold to see.
Taking the message bytes (starting at byte 23), you can run a frequency analysis and recover any sufficiently long english message from a single shard.
I have not come across a good library that implements SSS over finite fields that was easy-to-use, reliable, or robust. Any suggestions would be welcome.
On the topic of shamir shares, plugging a question I asked yesterday[1]: how do you manage them if you want to get them onto hardware? Do you just ask your tokens to encrypt the pieces and store the encrypted pieces along with the main ciphertext?
Something cool you can do that I recently found out about is use libgfshare to split a text file using whatever C and T shares you want. Then use scrypt on the split shares with a password you won't forget. Once encrypted with scrypt simply take a JPEG and `cat` the scrypt encoded share to the end of a JPEG and send it in an email to a friend, doing this for each share where you know you'd be able to get enough original copies back.
There are some tricks to do this correctly but once you have enough shares copy the scrypt binary data back to individual files and decrypt it. Then combine the shares and voila your friends have helped you keep something secret that even if enough of them turned on you they would still need the scrypt decryption password.
that's really cool, I've been playing w/ Shamir a bit. I noticed I could change the last character of one share and still get back the secret. not every replacement character worked, though. any idea why?
Is there any kind of standard for this? Every SSS implementation I've seen has its own custom format for the shards, so if you lose the program that reassembles them you can't recover the secret.
It's not a great choice though. The idea of horcrux is that any piece is enough which is basically exactly the opposite of what shamir secret does ;) It was a much better choice for a script with the same name I used a while ago that would duplicate backups on several storage systems.
Anyway, who cares about the name, it's a pretty cool website :)
Exactly (about it being the opposite of an "actual" horcrux). But this is not even the first (or the second) split-secret mechanism to make this same reverse analogy
[1] https://repology.org/project/ssss/versions
[2] https://packages.debian.org/source/jessie/ssss