Comment by nippoo
21 days ago
This kind of thing, widely implemented, would be a game-changer for dealing with assets after someone's death! I maintain my family's IT infrastructure (Google Enterprise admin, webserver etc) and I've been tempted to write down 1/4 of my password manager root password and give it to each of my family members - but then we run into the problem where if any one of them loses their shard, it's unrecoverable. Some kind of ECC would be great - ideally where I could print it out onto various bits of paper with a user-definable redundancy, or better still, some kind of reciprocal system where (say) 8/10 members of a trusted friend group/family ring could unlock any other member's password...
Don't worry even if your heirs have the password, it's extremely likely that Google will find the login attempts "suspicious" and try to verify your identity by sending SMS codes to a phone number you last had in 2005, despite your best attempts to prevent it.
Shamir secret sharing is the cryptographic thing that you want. You can can configure any M of N to be needed to recover the underlying secret.
(If you have a trusted third party, you can also enforce a cooling off period: e.g. that any attempt to access results in a notification to the account holder that if not denied within some time period, access is granted)
Something along the lines of reed-solomon codes could work for you:
If you want to share your password with M family members such that you only need N to agree to recover the original:
Split your password into ordered chunks.
Make a polynomial p, of power N where the p(1) = chunk1, p(2) = chunk2, ...
Evaluate the polynomial at M other points: p(N+1),p(N+2)...
Gives those M new points to your family along with their index (+1,+2,...).
If less than N family members get together, they will not be able to figure out the password much better than guessing. If N get together, they can interpolate their points to form the unique polynomial which will match p. Then evaluate p at p(1),p(2),... to get your original password.
If you put the whole password into 1 chunk, and pad the polynomial with random extra coefficients or points to make the polynomial of sufficient degree, then they get literally no information on the password without having at least N cooperate. If you make multiple chunks then they can do a little correlation between the chunks without knowing the whole thing.
This is sufficiently simple you can even work this out by hand without a computer, though it would be somewhat tedious.
Reed-Solomon is error correction, not encryption.
Reed-Solomon and Shamir secret sharing are quite similar (even though in practice they're used for very different things).
"Do not roll your own crypto" though.
There are much better systems for splitting data than just chunking it into N chunks, the most common is Shamir Secret Sharing[1] (the main benefit being that you can construct an M-of-N scheme easily and having N-1 shards provides you zero information about the secret). One word of caution -- a lot of software developers get enamored by the idea of information-theoretic security when they first run into it, but you eventually realise that useful applications of tools like SSS are actually quite rare.
Shameless plug: I wrote a project a few years ago to create PDF-based backups with sharded keys which would do exactly what I suspect you want[2], unfortunately I got stuck at the "make a nice UI for it" stage (everything works but it's just a CLI tool at the moment). I guess I should take a look at using an LLM for that these days... (I used this to store my password manager root password and necessary keys to pull and decrypt the encrypted backups of my server.)
[1]: https://en.wikipedia.org/wiki/Shamir%27s_secret_sharing [2]: https://github.com/cyphar/paperback/
A quarter of your password manager's password means it needs to be really long for it to not be bruteforceable if one or two quarters are recovered (on the order of at least 24 completely random alphanumeric characters)
Shamir's secret sharing scheme does not allow anyone to bruteforce it, no matter if they have 99 out of the 100 required pieces that unlock a 10-character password. If you want to do this sort of thing, I would recommend using a secret sharing scheme instead
We care about this porblem and are actively working on it, like the OP we also settled on shamirs secret sharing with a time lock mechanism.
However, there is still the issue of the service provider going offline or out of business which we don't have a solution for yet.
We have started with a good password manager and will be adding digital inheritance/social recovery soon! [0]
Take a look, thoughts and feedback welcome.
[0]: https://saveoursecrets.com
services going offline is a big concern for me! that's why my solution is offline first, I like the idea of the encrypted backup living in my friend's email inbox and working entirely without internet. a true hard copy.
for the time lock mechanism, how do you go about it? I'm interested in exploring using drand time lock, but that also relies on the service continuing to run (which is admittedly very likely) https://github.com/drand/tlock
You can give your password, or part of it, to your estate lawyer to attach to your will.
This is obviously more cumbersome, and probably costly, if you intend on changing your password. I guess you could change the part of it you don’t store with them.
yes! I am starting to do some planning on that myself, that's why I'm in that kind of mindset. If you know more people in this space, please share this with them! would love to get feedback
I wrote a project to do this a few years ago[1], it's mainly missing an automated mechanism to scan the PDFs and a GUI. Maybe you'll find it interesting.
[1]: https://github.com/cyphar/paperback
hey, this is a great idea! I'll link into your app from my readme. I really like that the PDF contains the entire dataset, not just the keys. I see lots of little details around organizing the PDFs, like document hashes, etc, very nice job!
Since you wrote it in Rust, I'd suggest compiling it to wasm and releasing a browser-based version
3 replies →