Topic: Generating key for long-term storage question (Read 979 times)

While I could use multi-sig to use different computers to generate each wallet (and thus prevent a single point of failure)– the multi-sig wallet as a whole can't be more secure than the single most secure computer in the system which would be my own laptop on a TAILS session.  And because of this fact I would/should use my laptop to generate every seed.  I suppose I could hypothetically split the generation of each seed into different sessions by turning off my laptop and letting the ram clear between making each seed.  But hypothetically, what type of attack could find the seed on one session and not in another?

So I think in my case or in cases where the computer generating the seed is secure that specific multi-sig advantage goes away in terms of a strictly backup solution.  For an average joe or collectively-used wallet though I think that advantage is non-negligible.

I could be wrong, but if I can't trust a TAILS live session on my personal laptop which will have no Internet connection then it seems all software solutions are unsuitable for generating bitcoin wallets. Fortunately, the fact that bitcoin still exists kinda proves that attackers do have some limits.  I can't assume all hardware has been bugged and is just waiting to attack me.  Beyond a certain level paranoia is detrimental

I looked into using multi-sig, but from what I can tell it is not appropriate for my use case.

In the event that something actually did happen to me the people I have designated to rebuild my wallet would need at least 3 pieces of information (either 2 seeds and 1 mpk, or 3 seeds).  If they don't have these the wallet goes poof ( it is either unable to be rebuilt or unable to sign transactions).

To solve it I would have to give each person not only his seed, but a different person's mpk so that if one person had his information lost/destroyed the other two people would still have the minimum 3 pieces of information.

At this point, however, the solution is simply bulkier than using ssss.  The only (theoretical) advantage is that the seeds are built with 2.x, but it doesn't justify the added complexity imo.

Have I understood the mechanics of rebuilding a multi-sig wallet correctly?

EDIT

Abdussamad did mention that the seeds can all be generated separately as an advantage which is true.  I have to consider that.

Sounds like you have a pretty good handle on things .


It depends on your use case, but yes there can be an incentive. If someone you're sending a tx to also controls your exit node, they may be able to convince you that a tx never went through, and that you need to send another. If Electrum chooses different UTXOs for the second tx, then you've been successfully scammed. It's probably more a theoretical attack than a practical one for most people....


That's a good idea, assuming that 2 of 2 or 2 of 3 is flexible enough for OP.

Instead of using ssss you should create a multisig electrum wallet. The advantages are:

- All the private keys are never on the same device so the wallet can't be compromised from the outset.

- The mnemonics have checksums in them so that protects you from typos and helps with seed recovery if you have only a partial seed.

- No need to use external tools. You use native electrum functionality.

Yes this is cold-storage.  Actually, my coins are already in cold storage with paper wallets.  The problem is that if something happens to me (amnesia, coma, death, etc.) then those might be lost forever.  I believe that something physically happening to me is many many orders of magnitude more likely to happen than someone hacking a properly made Electrum seed.

I am choosing an HD wallet over a paper wallet because it seems the most fool-proof choice (I/they may not know how change addresses work) which means I have to use Electrum or Armory and since Electrum (and ssss) is pre-installed on TAILS it seemed the simplest way to go.  I can provide a simple step-by-step guide that never requires an Internet connection and won't store anything.

I am aware that TOR is not perfect, but if it keeps everyone except a global adversary in the dark its good enough.

I am also aware that Electrum servers can omit information from me, but that seems more like an inconvenience instead of an attack.  Is there any incentive to cause someone to actually do this?

I will probably update my storage method again in 3-5 years as better methods will probably exist by then.

I'm not clear if TAILS + Electrum is a good thing. Electrum servers do not require TLS. A malicious Tor exit node could spy on your transactions (but of course not trace them back to you easily), and I believe it could also prevent you from seeing transactions (whichever one(s) it chose). It can't easily fake the existence of transactions, nor lie about transaction contents/values though.

Assuming your 128 bits of entropy are from a good source, there's no significant known difference in security between the two today.

However, Electrum 2.x's master private key -> individual private key derivation process (a.k.a. BIP-32) is more conservative/paranoid then Electrum 1.x's derivation process. I don't think anyone knows if this more conservative approach might one day be an actual security advantage or not. I certainly don't know the answer to that one....

BTW, all this talk of seed security pales in comparison to the use of cold storage. IOW, if you're not already planning on cold storage, 128 vs 256 or 1.x vs 2.x just doesn't matter. It's like worrying over how lock-pick-proof your door is even though you leave your window open.... are you planning on cold storage?

How much of a difference in seed generation security is there between an electrum 2.x seed over a 256-bit 1.x seed?

I plan on doing everything inside TAILS so hopefully that erases my tracks.

Electrum 1.x binary seeds are 128 bits long. They are (AFAIK) the only format that Electrum (1.x or 2.x) can easily restore from which is that short.

You could download Electrum 1.9.8 and have it create a wallet for you (after creating it, you can upgrade to Electrum 2.x), and then run the get_seed code above, or if you wanted to generate your own by hashing with SHA-256 a well-shuffled deck, I think either would be fine. Keep in mind that it's a bit dangerous since any malware that manages to get access to your binary seed as you manipulate it can steal your BTC, e.g. you don't want it accidentally stored in your .bash_history, or anywhere else for that matter.

I used the code you provided on an empty wallet (for Electrum 2.x) and got this:

u'xprv9s21ZrQH143K4HiothRzU69nbQoG6vM8MmuREYEbB4WcBbRMCxvVxpGtEojy15b7XmA9Vqk1wda g3DoedvAqNJ7FC1hjEoeGC4aLnw88Cw9'

but this is actually longer than the 13 seed words so it accomplishes the opposite of what I wanted which was to have the secret shares as short as possible.

When I put the 13-word string from an Electrum generated seed as my input for ssss-split it will assume its extended ascii (or so I believe) and thus represent 8-bits per character.  If the Electrum seed is approx. 88 characters long ssss believes I am giving it 704 (8*88) bits and so I have a really long share (some of my shares will be on paper so shorter would be better) .  Using the -s option to specify the bits fails because it says the input string is too long.  I was hoping to extract just 128-bits in a compact form such as 32 hexadecimal characters so that the output from ssss is shorter.

And after reading the post that you linked I believe the safest option is to just trust Electrum to generate the seed.  But if I want a short share I have to manually restore from 32 or 64 hexadecimal characters generated outside of Electrum so that I can put that into ssss.  If the entropy is good is that method dangerous?

For old-style (Electrum 1.x) wallets, type this in the console:

For new-style (Electrum 2.x) wallets, it's:

Please note that for new-style wallets, if you keep only the master private key (and later restore from it), there's no way to get the mnemonic (seed words) back. This isn't a problem from a bitcoin funds point of view, but it might be an inconvenience in the future if you ever want to use your mnemonic as a backup later.



A Bitcoin private key has at most 128 bits of security. There's no advantage of using more than 128 bits of good entropy, however it's very hard to know if your entropy is good or not.

If you're not certain of your entropy source, it might be beneficial to use more entropy. IOW, if you have 256 bits of entropy from some source, and if that source actually (unbeknownst to you) has only one bit of entropy for every two bits of output, then you end up with a 256 bit number with only 128 bits of entropy. In short: longer can't hurt, especially if the entropy source is questionable, though it may be inconvenient.



Using the --entropy option with poor entropy does hurt: entropy entered via this method replaces some of the entropy (or all of it for the restore method) normally gathered from the OS. If your provided entropy is worse than what the OS can provide, this could be a problem.

Note that you can use the --entropy option with, say, a deck of cards (which is easier than dice IMO), see here: https://bitcointalksearch.org/topic/m.10644190. If you're truly paranoid, you could ask for a 256 bit seed, and use the method in that last URL to provide 128 bits of entropy from a shuffled deck. That way, you'd get 128 bits from the deck, and 128 bits from the OS.

I want to use Shamir's secret sharing on my Electrum seed for long-term storage, but for the sake of security there are some things I'm not sure about.

The first is that I would prefer to split the seed in its hex form instead of its word mnemonic form.  When I run "electrum getseed" though it only outputs the words.  Is there an option or way to access the hex seed without manually creating one myself and restoring from it?

Second is that now Electrum can generate a 256-bit seed.  Is there a practical benefit to this since a Bitcoin private key can only have at most 160 bits of security?

Third, I want to roll some dice and put in that as some extra entropy.  If I use the --entropy option to do this would there be a problem if the dice turned out to be biased or would this option at worst only provide no benefit?

-or-

would it be better to hash a bunch of dice or a deck of cards and use the restore function?

thanks.