Quote from: hatshepsut93 on February 19, 2020, 06:02:18 AM

There are secret-splitting schemes that allow you to create shares in a way that doesn't compromise the security of your secret. Shamir's Secret Sharing is the most famous such scheme, and Ian Coleman has an online tool for it on his site - https://iancoleman.io/shamir/

So, why settle for a fraction of security if you can keep full security?

I have looked into the shamir schemes but unfortunately this is not a solution at the moment as the scheme is not compatible to split BIP39 Mnemonics into a human readable format (Writing down long strings of HEX by hand is not the best idea), It would need to be compatible with my Ledger. They are supposedly working on a SLIP39 implementation, like Trezor just released. This would be the ideal solution as it retains 128-bits of security even if 1 share is compromised.

Quote from: o_e_l_e_o on February 19, 2020, 11:35:18 AM

This calculation is incorrect. It's not as simple as just adding 88 bits to 12 bits to reach 100 bits. The majority of seeds which could be brute-forced from knowing 16 out of 24 words won't be valid because the checksum will fail, and so there is no need for an attacker to then start brute-forcing diceware words for them - they can simply be discarded. It is more accurate to work out the length of time to brute-force 83 bits to calculate all possible seeds, and then the length of time to brute-force 12.9 bits for each seed.

Your estimation of 1 quintillion guesses per second is obviously way out of the current scope of computing power, but if you are looking decades down the line to potential inheritance, then who knows what will be possible. For illustration, reducing the entropy in the calculation from 100 bits to 83 bits, then your number of 40,000 years instead becomes around 4 months.

Shamir's Secret Sharing as mentioned by hatshepsut93 is another option, but be aware that there is no standard implementation of it. If you do use Ian Coleman's site do split your seed this way, you should be keeping a couple of copies of the code in various places in case his site and GitHub disappear from the internet in the future.

You make a valid point and this makes sense, plus in theory the adversary would only need to produce a list of all valid combinations that pass checksum and skip checking each combination for a non-zero balance until he/she is brute-forcing the passphrase (which would be trivial at 12.9bits). Seems this method may be less secure when using a weak passphrase since the adversary would be able to bypass the key-stretching and address checking for the majority of the attack.

Quote from: pooya87 on February 19, 2020, 06:12:09 AM

the problem with that method is that it is not an encryption technique and also you will have to have 3 completely separate, isolated and secure places to store each part at and it is not easy to have it. if you are just storing all at home, it is not safe and you can't trust any other person to store it with them either.

adding an extra string (known as passphrase in BIP39) could be a good idea to add another layer of security but i personally prefer simply encrypting the whole thing with AES using a very strong password and then storing that single result in a safe place and the password of it in another.

I already have my unencrypted 24-words in 3 completely separate locations. One of these copies is with a trusted 3rd party. Im not worried about the person who is caring for it compromising it, more from other people who may come across it (Thieves, Burglars, Snoopy Guests, Guests Children etc.) or if I was to leave a copy in a safety deposit box that it couldn't be compromised by malicious staff or security camera immediately. Id rather have some security from this then none. Adding a passphrase would only be an option if it was high entropy (over 85bits, anything under this would have less security then the missing 8 words), and then I would have the same issue of having to store the passphrase somewhere safe.

I really appreciate the responses