Currently doing a different startup, but certainly an idea for a future one.
https://packages.debian.org/trixie/ssss is a nice and rather straightforward implementation.
(Actual GPS is a little more complicated than that because the real system needs accurate time information.)
Since Shamir Secret Sharing is information-theoretically secure (if you do not know k points from the k-out-of-n secret then all secrets are equally plausible even when bruteforcing), the bitsize of your field can be whatever you want (but obviously bigger than the bitsize of your secret, you can't hide 100 bits in a finite field of 5 elements).
Usually, you don't want an attacker to be able to bruteforce your secret (while the scheme is ITS, your secret typically isn't, e.g. the seed of your wallet), hence randomness can be added to your secret and the bitsize of the field is taken big enough to thwart these attacks.
Depending on your attack model, an 80-bits or 128-bits field is more than secure enough, hence a share bitsize slightly above 80 or 128 bits.
And regarding quantum computer, since the scheme is ITS no attacks can exist.
As I understand it, quantum computing changes nothing here — if you're missing even one point, that last point could change the secret to anything at all, with no way to disambiguate.
3 of 4: A B C D
- OR -
2 of 3: E F G
- AND -
1 of 1: H
Though there's something to be said for the simplicity of the current design.
key is protected by a 3 of 3 keys.
1 protected by 3 of 4 (i.e. SSS the key into a 3 of 4) 1 protected by 2 of 3 (i.e. SSS the key into a 2 of 3) 1 that just is.
so you take your original key and SSS into a 3 of 3.
you take part 1 and SSS into a 3 of 4, and take part 2 and SSS into a 2 of 3.
https://bs.parity.io/ -- http://passguardian.com/ -- https://iancoleman.io/shamir/
I gave that to some members of my family and instruct them to give them to my wife in case I die.
Thanks a lot Sir.
Good work doing it. I guess now I don’t have to. :D You may have gained a customer from this HN thread.
Wrote my thoughts about that here: https://eternalvault.app/blog/why-we-are-adding-lifetime-pri...
And it feels good to know that there are people out thinking about this, makes me happy truly and if you want to try out the platform, welcome aboard, happy to walk through it if needed. :)
One thing I had been thinking about was that it’s important to be extremely open about the algorithms and infrastructure required, with a very transparent whitepaper on how it works (enthusiast level discussion of the technical details) and how you have designed the company to be extremely sustainable. I think your job is to convince people of two things: 1) this actually respects my privacy in a way I can verify myself (or lean on the technical expertise of other outside observers), 2) this company actually has a chance of surviving until I die.
If I can see those two things are true, a $199 lifetime purchase is a no-brainer (and that probably covers a dozen lifetime members’ operational costs). :D
Regarding (2), that is the most common question I get and honestly I don't know if I have the best answer for it, but here's what I have, I have two vaults for myself (of course I use Eternal Vault myself), one for family and one for business, in the business vault I have few documents including one called "Business continuity plan" which lays down all of my raw thoughts around how eternal vault is built, core technical things, infrastructure, dooms day trigger etc, and other business specific documents, right now since I don't have any heir, I have added few close people to it who are also fairly technical to keep it running, but eventually my idea is to expand on it in such a way that if I'm removed from the equation, the product can still sustain itself both business and ops wise, but I can totally understand why someone would trust a stranger on the internet, so I'm actually not sure how can I make the answer for 2nd much better, what do you recommend?
The other thing is being very transparent about the real world incremental cost of a user’s data. It slightly undermines the price point, but being able to say “look, incremental storage cost for your data over your lifetime is 33 cents. We have a bond that covers our current user base in perpetuity ten times over” is pretty compelling. You can say “yes, you’re paying way more than the incremental cost, but you’re paying for the care that went into making sure it’s got longevity.”
I can’t stress enough how happy I am for you that you built this thing that I consider a fabulous idea. I have an idea about how you can market it if you want to hear it. Let me know the best way to email you.
In my idea, the doomsday trigger handling might be difficult if it was a truly offline page, so I've not yet thought it fully on how it can be executed well, I'll revisit that idea again with fresh eyes.
And thanks for the reach out, would love to chat more on email!
SSS does suffer though for some serious weaknesses, i.e. it trusts the shareholders. A cheating party can submit a fake share during reconstruction, corrupting the recovered secret, and honest parties have no way to detect this something that verifiable secret sharing fixes.
Anyway threshold crypto is a very elegant field and the math is there is really beautiful.
In this way, people could act as backups for one another with plausible deniability of what's being stored.
"The useful part is not that the secret is hard to compute from too few shares. It is that too few shares contain no information about the secret. With one share missing, every possible secret is still possible."
Reminds me of factoring numbers with the Quadratic Sieve or its variants. You find a system of congruences mod n that eventually allow you to compute prime factors, but until you have enough of them that isn't possible. I've often wondered... Each congruence must contain some information right? What space are we reducing degrees of freedom in?
Same thing here, each piece restricts the space of polynomials, but does not restrict it enough to tell where the key crosses the axis.
https://www.cloudflare.com/learning/dns/dnssec/root-signing-...
https://blog.apnic.net/2021/10/12/dns-security-and-key-cerem...
https://medium.com/@amanat361/shamir-secret-sharing-the-stor...
If I use 3 shares and require all three to recover, then I think I could let the 3 points define a plane. Then the plane would intersect the axis at a unique point.
If I want 4 or more shares, I can make them by just generating more points on that same plane. Then I think any three of those should recover the secret. So it seems like that would all work about the same as with the polynomials? Then I can go to still more dimensions when I want to require more shares to reveal the secret.
As a bonus, when you refresh the shares, you'll discover that at least a couple of your trusted parties have absolutely no memory of receiving that mysterious piece of paper from you back in 2022.
but you can also just use Reed-Solomon and split the payload, the difference with Shamir is that you lose information-theoretic security (you lose it the moment you use encryption anyway) and the payload also needs to undergo an all-or-nothing-transform (AONT).
AONT transforms the entire payload into an encrypted blob which also serves as its own key, a withheld piece is a de facto encryption key. this is required because Reed-Solomon can have pathological cases where pieces leak information.
> Reed-Solomon is an Erasure code
> Those leakage models are gnarly.
Yes, you can just GF(256), but if you're worried I'd also just use a prime field instead.
Vibe-coded a little playground where you can generate secrets, see the polynomial, combine the secrets, and in general, play around:
Fascinating how sometimes in different languages one word can have opposite meaning and the other times one word can have similar meaning.
By who? My SO is now passably conversant in Malayalam after watching their cinema during the covid lockdowns (~1y to 2y).
For what we needed, we intentionally wanted both people to be at the same terminal (it was going to be used to give shell access to a specific unix account that ran a critical system).
That mean that we could implement it as a setuid (root) binary that required both users to authenticate. It had a config file that worked like sudoers, and defined a list of commands that could be called, how many people were needed to authenticate, and which unix groups they had to belong to.
Your environment is unlikely to have all of that already, so you'll need to figure out equivalents for all those. But I think you're going to need a local service running as root and it's going to need to be able to tell the difference between distinct human users, if you want secure. Just typos is way easier.
https://github.com/Argonne-National-Laboratory/Pam-2man-Auth
- They could no longer read your data
- Additional redundancy (as you only need 2 to be available)
- Compared to other secure storage apps which rely on a master password, which if you forget, you are screwed, you could still use all the usual account recovery methods.