8

I noticed that Electrum seeds are 13 words long if the wallet has been created by Electrum but if I used a random hex string to create the wallet it always was 24 words long.

So before I wrote this question, I wasn't quite sure that I remembered the number of words when using a random hex string correctly. I typed down some 32 hex digits and created the wallet. Note that for this I didn't use a source of randomness. Instead, I just thought of hex digits and typed them in. To my surprise, the seed only was 12 words long. I then sha256summed my desktop wallpaper to get a more random 32 digit hex number and was back to 24 words as a seed just like when I did a few experiments some days ago using xxd in combination with /dev/urandom.

So why the different lengths? Clearly, I'm a very poor source of entropy. So Electrum might have compressed the hex number I gave it down. But why are seeds of wallets generated by Electrum only 13 words long whereas wallets created using random 32 digit hex numbers are 24 words long? Shouldn't Electrum use a good source of entropy? Maybe even /dev/random instead of /dev/urandom xored with some stuff it finds itself and therefore create wallets with a 24 words seed?

I don't even see how 13 words are enough to encode a 32 digit hex number. You'd need to encode 256 bit / 13 = 19.69 bit in every word, so you'd need at least 2^19.69 words = 847'180 words. (If you get a different result, use the exact intermediate result.) The English language has 1'025'110 words which would be enough but that's counting words like "pneumonoultramicroscopicsilicovolcanoconiosis". Electrum only uses very basic English words of which there aren't nearly as many as 847'180.

How does Electrum even create several addresses from a single 32 digit hex number? The wallet import format this website generates if I enter the hash of my wallpaper doesn't match any of the private keys in the Electrum wallet. I'd expect the first private key to be the one generated from the 32 digit hex number I entered and all others to be generated using a deterministic key derivation algorithm.

Improve this question

2 Answers 2

Reset to default
3

The 13-word mnemonic is just a way to encode a 128bit number into something human-readable and memorable. The 13th word is a checksum, and 12 words would suffice to recover the number encoded. You should always generate it by truly random means to reduce likelihood of someone generating the same as you and running away with your coins. Some more info can be found here.

The wordlist consists of 2048 words since circa Aug 2014. If you want to know how many words you need to encode a 128bit number, you can calculate yourself.

Log_2048(2^128) = 11.63636364

The 128bit number is actually a 32 digit base16 ("hex") number (2^128 = 16^32).

I tried to replicate what you did, and used electrum wallet recovery function. When inputting a 32 digit hex number, I get a 12 words mnemonic. It would also accept a 64 digit base16 number, and then I'd get a 24 words mnemonic, which makes sense considering how it's generated. However, I'm having trouble replicating what you experienced, to get a 24 word mnemonic from a 32 digit base16 number.

Now, what is that 128number used for? It's used to generate your master private key, master public key and all the keypairs in your wallet. It's nicely detailed here.

The total number of possible extended keypairs is almost 2^512, but the produced keys are only 256 bits long, and offer about half of that in terms of security. Therefore, master keys are not generated directly, but instead from a potentially short seed value.

  • Generate a seed byte sequence S of a chosen length (between 128 and 512 bits; 256 bits is advised) from a (P)RNG.
  • Calculate I = HMAC-SHA512(Key = "Bitcoin seed", Data = S)
  • Split I into two 32-byte sequences, I_L and I_R.
  • Use parse_256(I_L) as master secret key, and I_R as master chain code.

In case I_L is 0 or ≥n, the master key is invalid.

BIP32

Improve this answer
8
  • I didn't get a 24 word mnemonic from from a 32 digit hex number. However, I apparently have made a mistake. I wrote that I sha256summed my desktop wallpaper to get a 32 digit hex number with a lot of entropy. However, a sha256 hash as 64 hex digits long. I don't know why I did this mistake and can't remember how long the other number (the one I made up while typing it in) was. However, it still doesn't make sense to me that I got a 12 word mnemonic. Furthermore it doesn't make sense to me that Electrum only uses 128 bit keys to generate something that can hold a lot more entropy / information.
    – UTF-8
    Commented Jun 11, 2016 at 20:47
  • 128bit = 32digit -> 12 words, 256bit = 64digit -> 24 words. Apparently, 128bits is considered more than enough considering number of possible combinations and time it would take to brute-force them all, but you're free to use 256bit. I wouldn't agree that your wallpaper is a good source of entropy, though. Taking a photo in low-light could be, considering all the noise introduced when doing so.
    – JollyMort
    Commented Jun 12, 2016 at 6:11
  • But how come it's not 13 words since there should be one as a checksum? That's the part about it I don't understand. I only said that the sha256 hash of my wallpaper has high entropy. That's because if you put anything into sha256, you'll get something with high entropy out. It doesn't matter in this case that my wallpaper itself doesn't have high entropy (in fact it's a grayscale image with an RGB color profile) or isn't particularly secret. I wanted a hex number with high entropy which I can easily get hold of again without storing it somewhere.
    – UTF-8
    Commented Jun 12, 2016 at 10:56
  • Don't confuse entropy with length. Yes you can feed anything to sha256, but if I feed it "aaaaaa" and get some 256bit number, it won't really have high entropy. It may LOOK like it has, but it won't. Somebody somewhere could get the idea to do the same what you did and take your coins. The source should be as unpredictable as possible. You could use dice rolls to generate your key - you'd need about 50 rolls for 128bits of entropy though. As for the 13th word, I guess when importing directly from user generated seed, it doesn't calculate it. Would need to investigate this a bit more, though.
    – JollyMort
    Commented Jun 12, 2016 at 11:48
  • For every high-entropy piece of data, there is a hash function which maps a simple input to that high-entropy piece of data. Don't confuse high entropy with stemming from randomness or being hard to guess. Anyway, how is a 12 word seed possible?
    – UTF-8
    Commented Jun 17, 2016 at 15:53
2

Great question!

So you're thinking about the word-encoding incorrectly. The first thing you have to do is lob off that 13th word, as it is used as a checksum, so there are actually only 12 words. Now there are lots of options for Electrum to take to derive its master key, and there are two that are of particular interest.

  1. The simplest way is just to hash the actual words, so sha256(seed phrase goes here). The advantage of this is that future wallets don't need to store old word lists if the word list changes, they can just hash the words that have been entered, check it against the checksum (there are ways of encoding the checksum that also don't require keeping the wordlist), and then if it passes restore that wallet.

  2. The way that Electrum used to do the derivation, that is still used by Monero and others, is by having a wordlist with a fixed length of 1626 words. The position of the words in the wordlist matters! Thus a 12 word seed is the equivalent of 1626^12 = 3.4154387e+38. This number is just a bit larger than 128 bits: (2^128)-1 = 3.402823669e+38.

To properly calculate entropy, given a fixed number of words / symbols / characters, we use the following formula:

H = log2(N) * L

where H is the number of bits, L is the length of our password (12, in the case of Electrum), and N is the total possible number of symbols (1626 in this case). Thus, H = log2(1626) * 12 = 128.005344, so 128 bits of entropy in the Electrum seed.

As to how Electrum creates several addresses from a 128-bit number (or a 256-bit number in the case of hashing the seed words), the seed derivation works by increasing a "nonce" and deriving an address from that. So, by example, if we pretend that we have 1234 is our seed, then we could increase that seed by 1 for each address derivation. If we use a simple sha256 hash of that as our private key, then we get the following addresses:

NonceFinal SeedAddress
0 12341B3PHXB6g5YGLvzTkxrrPEdLbpvfEoC5Qi
1 12351NxaF9cYPL53fNTHMN6wtmq1w8bmHEe3gp
2 12361DPF9wFiuFowUK4NwJdbd2W9L59bPPnWNM
3 123713ehhpMndUoh5E4QcHJ7QSWwuKC7ySpxrL
4 123817CF5qesU9KXBHAsa9tEz1126kqSDy56tC
5 12391MfTGTiszztzzjzKajvS1Wc3TznqpfyPh7
6 124016t3QqxUVssdTAYUibdY8K4aCFYsP6pUWE

This is obviously oversimplified, and not the derivation that is used in most BIP32 implementations or in Electrum. As to how they are restored, you simply keep deriving addresses until you hit a bunch in a row that are unused. This is called a lookup gap, and is normally configurable.

Improve this answer
6
  • If this is true, Electrum only uses 1/(3.4154387*10^38) of the available key space, significantly impacting the difficulty to guess a private key. You now only have to try 3.4154387*10^38 different private keys instead of 1.157920892*10^77. I do realize that that's still a huge number but don't forget the birthday paradox and that there might still be huge increases in computational power. Offering the user to decide whether they want 13 or 25 words (128 bit with projection to 256 bit or 256 bit straight away) shouldn't be too much of a deal.
    – UTF-8
    Commented May 23, 2016 at 11:59
  • This doesn't explain the 12 words nor the 24 words, though. Let's talk about the 24 words first: That can't include a checksum. So every or almost every 24 words (of the list Electrum uses) combination had to be valid. However, Electrum won't accept this one I just tried.
    – UTF-8
    Commented May 23, 2016 at 12:05
  • Now to the 12 words: It had to somehow compress my number and store it in 11 words + checksum (unlikely) or scrap it and just project it onto something else which would enable me to get back the same wallet in the future using Electrum but not enabling me to access my money in a wallet identified by that 256 bit number nor enabling me to access money I put there while using Electrum from a different wallet. The latter part of course would only work if HD wasn't used. Therefore, I think it's the projection thing: Electrum might allow the user to enter their own random number which is then used
    – UTF-8
    Commented May 23, 2016 at 12:08
  • instead of using entropy from the OS. Of course, that's just guessing and would be bad because you couldn't restore a wallet of which you only know the private key (in hex, not its wallet import format) using Electrum. To do that, you'd need a different tool.
    – UTF-8
    Commented May 23, 2016 at 12:10
  • Re: "every or almost every 24 words had to be valid" - if memory serves it also has to be a valid EC point, so not every combination will work.
    – Riaan Swart
    Commented May 23, 2016 at 14:36

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.