<p>When creating a new seed, Electrum 2.x does pretty much the same thing as vanity address generators, or for that matter Bitcoin miners... it "grinds".</p>

<p>It generates a seed based on some entropy and a <a href="https://en.wikipedia.org/wiki/Cryptographic_nonce" rel="nofollow">nonce</a>, and checks if the seed's <a href="https://en.wikipedia.org/wiki/Hash-based_message_authentication_code" rel="nofollow">HMAC</a> starts with the required byte sequence (the "checksum"). If it doesn't, it increments the nonce and checks its HMAC again.</p>

<p>If you're interested, the code which does this is <a href="https://github.com/spesmilo/electrum/blob/b3f1f04312210a8c7009302850d4f80267545392/lib/mnemonic.py#L158-L166" rel="nofollow">here on GitHub</a>.</p>

<p>It should be noted that Electrum seeds have (by default) 128 bits of entropy. As a result of this grinding, Electrum discards (for standard wallets with a checksum of 0x01) 255 out of every 256 potential seeds. This effectively decreases the entropy in a seed by 8 bits (the length of the checksum). In order to compensate for this, Electrum 2.x adds an additional 8 bits to the total seed length, which brings the seed length to 136 bits and the entropy back up to 128 bits.</p>

CC BY-SA 3.0
2015-05-22T04:47:17.110Z
Note that it's considerable faster than most vanity generators, since it only needs to do ~128 HMAC-SHA2 operations, which is really fast.
Nick ODell
CC BY-SA 3.0
2015-05-22T06:09:09.453Z
Ah ha so that's why the True loop is used. I thought it was being used just once as `while old_seed` seems more intuitive to me. I can see the rationale now, especially after running successfully finding numerous cases of Electrum 1 seeds which returned a 01 hmac. I'm curious... is it possible to implement a better system whereby an old seed can never be interpreted as a new seed or is this just the most appropriate given it's a hash based seed?
Wizard Of Ozzie
CC BY-SA 3.0
2015-05-22T12:25:21.253Z
@WizardOfOzzie One idea that comes to mind which Electrum could implement (but hasn't yet) is to throw out the standard BIP-39 wordlist, and use a custom one which shares no common words with the Electrum 1.x list. Electrum already [eschews BIP-39](http://bitcoin.stackexchange.com/questions/36839/electrum-2-0-non-bip39-32-standardisation-complicates-matters-immensely-why#36889), so there's no reason to keep the same wordlist. The BIP-39 wordlists aren't even all that good—they violate BIP-39's *own* recommendation of no similar words (auction/action, motion/emotion, garage/garbage, etc...).
Christopher Gurnee
CC BY-SA 3.0
2015-05-22T13:15:17.490Z
@ChristopherGurnee I was just about to raise the same solution after pondering it all day. It is a much better delineation both programmatically and intuitively IMO
Wizard Of Ozzie
CC BY-SA 3.0
2015-05-23T02:21:12.440Z
@nickodell you're right. I ran it to be sure :) While we're on the topic, what is the point of running the `ecdsa.utils.randrange` and incrementing the nonce when it's just as likely running the loop for a random number will return a valid seed?
Wizard Of Ozzie
CC BY-SA 3.0
2015-05-23T02:22:28.067Z
@WizardOfOzzie No clue on that one. The same thought struck me.
Nick ODell
CC BY-SA 3.0
2015-05-23T02:23:57.343Z
@nickodell Sha512 hmac btw. Interestingly, and this is news to me, python hashlib has a pbkdf2_hmac function which is a hell of a lot faster than my optimised pbkdf2 function
Wizard Of Ozzie
CC BY-SA 3.0
2015-05-22T04:36:46.257Z
2015-05-22T13:51:04.963Z
2015-05-22T13:51:04.963Z
Christopher Gurnee
<p>Electrum version 2 creates a seed from a random number which is then encoded as a mnemonic. The seed is validated by checking that the hmac begins with the bytes <code>01</code> or <code>101</code> for standard and 2fa types, respectively. </p>

<p>I have looked at the python code on github and indeed it does return the 01 byte but I am still confused as to <strong>how one can ensure a hash is going to start with a predicted value</strong> (<code>01\101</code>). </p>

<p>How can this be so? Is it that I'm missing the nuance of what the code does or the concept of how hmac works</p>

<electrum><cryptography>
Electrum 2 validation: how is the HMAC always 01...?
Wizard Of Ozzie
# Electrum 2 validation: how is the HMAC always 01...?

(Asked by: username_0 on 2015-05-22)

Electrum version 2 creates a seed from a random number which is then encoded as a mnemonic. The seed is validated by checking that the hmac begins with the bytes `01` or `101` for standard and 2fa types, respectively.

I have looked at the python code on github and indeed it does return the 01 byte but I am still confused as to **how one can ensure a hash is going to start with a predicted value** (`01\101`).

How can this be so? Is it that I'm missing the nuance of what the code does or the concept of how hmac works

**Tags:** electrum, cryptography


---

## 1 answers

### Answer by username_1 on 2015-05-22. Score: 3 | Accepted answer

When creating a new seed, Electrum 2.x does pretty much the same thing as vanity address generators, or for that matter Bitcoin miners... it "grinds".

It generates a seed based on some entropy and a [nonce](https://en.wikipedia.org/wiki/Cryptographic_nonce), and checks if the seed's [HMAC](https://en.wikipedia.org/wiki/Hash-based_message_authentication_code) starts with the required byte sequence (the "checksum"). If it doesn't, it increments the nonce and checks its HMAC again.

If you're interested, the code which does this is [here on GitHub](https://github.com/spesmilo/electrum/blob/b3f1f04312210a8c7009302850d4f80267545392/lib/mnemonic.py#L158-L166).

It should be noted that Electrum seeds have (by default) 128 bits of entropy. As a result of this grinding, Electrum discards (for standard wallets with a checksum of 0x01) 255 out of every 256 potential seeds. This effectively decreases the entropy in a seed by 8 bits (the length of the checksum). In order to compensate for this, Electrum 2.x adds an additional 8 bits to the total seed length, which brings the seed length to 136 bits and the entropy back up to 128 bits.

> **Comments:**
> **username_2**: Note that it's considerable faster than most vanity generators, since it only needs to do ~128 HMAC-SHA2 operations, which is really fast.  
> **username_0**: Ah ha so that's why the True loop is used. I thought it was being used just once as `while old_seed` seems more intuitive to me. I can see the rationale now, especially after running successfully finding numerous cases of Electrum 1 seeds which returned a 01 hmac. I'm curious... is it possible to implement a better system whereby an old seed can never be interpreted as a new seed or is this just the most appropriate given it's a hash based seed?  
> **username_1**: @username_0 One idea that comes to mind which Electrum could implement (but hasn't yet) is to throw out the standard BIP-39 wordlist, and use a custom one which shares no common words with the Electrum 1.x list. Electrum already [eschews BIP-39](http://bitcoin.stackexchange.com/questions/36839/electrum-2-0-non-bip39-32-standardisation-complicates-matters-immensely-why#36889), so there's no reason to keep the same wordlist. The BIP-39 wordlists aren't even all that good—they violate BIP-39's *own* recommendation of no similar words (auction/action, motion/emotion, garage/garbage, etc...).  
> **username_0**: @username_1 I was just about to raise the same solution after pondering it all day. It is a much better delineation both programmatically and intuitively IMO  
> **username_0**: @username_2 you're right. I ran it to be sure :) While we're on the topic, what is the point of running the `ecdsa.utils.randrange` and incrementing the nonce when it's just as likely running the loop for a random number will return a valid seed?  
> **username_2**: @username_0 No clue on that one. The same thought struck me.  
> **username_0**: @username_2 Sha512 hmac btw. Interestingly, and this is news to me, python hashlib has a pbkdf2_hmac function which is a hell of a lot faster than my optimised pbkdf2 function  

---

