<p>This is specified in <a href="https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki" rel="noreferrer">BIP 39</a> itself:</p>

<blockquote>
  <p>To create a binary seed from the mnemonic, we use the PBKDF2 function with a mnemonic sentence (in UTF-8 NFKD) used as the password and the string "mnemonic" + passphrase (again in UTF-8 NFKD) used as the salt. The iteration count is set to 2048 and HMAC-SHA512 is used as the pseudo-random function. The length of the derived key is 512 bits (= 64 bytes). </p>
</blockquote>

<p>So the seed that's used is essentially a 512-bit hash of the mnemonic, which explains why it's 512 bits long (= 128 nibbles).</p>

<p>The BIP doesn't explain why they do this, but I would assume that it's convenient to know that the seed will always be a certain size, regardless of how much entropy is actually used to generate it.  This means, for instance, that key generation code can be written to always work on 512 bit seeds.</p>

CC BY-SA 4.0
2019-04-25T06:07:36.197Z
The need to have a constant size seed doesn't explain the use of PBKDF2 over say, SHA256/512 which are already used. My assumption would be that the PBKDF2 function was chosen so that in the event the mnemonic phrase is leaked, but is password protected, it is computationally less feasible to brute force passwords under PBKDF2.
Mark H
CC BY-SA 4.0
2019-04-25T05:50:44.307Z
2019-04-25T05:50:44.307Z
Nate Eldredge
<p>BIP39 converts mnemonic 
<code>"zoo zoo zoo zoo zoo zoo zoo zoo zoo zoo zoo wrong"</code></p>

<p>to the fairly long seed 
<code>"b6a6d8921942dd9806607ebc2750416b289adea669198769f2e15ed926c3aa92bf88ece232317b4ea463e84b0fcd3b53577812ee449ccc448eb45e6f544e25b6"</code></p>

<p>Good tool to play around <a href="https://iancoleman.io/bip39/" rel="nofollow noreferrer">https://iancoleman.io/bip39/</a></p>

<p>What's the point of so long seed value when the entropy value of random 12-words mnemonic is much smaller?</p>

<ul>
<li><p>2048 words list dictionary = 2^11 => 11 bit</p></li>
<li><p>12 words * 11 bits = 132 bit</p></li>
<li><p>in hex format (4 bit for character) is 132/4=33 charter long, vs 128 of seed</p></li>
</ul>

<bip32-hd-wallets><mnemonic-seed><bip>
Why seed from BIP39 mnemonic phrase is much longer than entropy?
lebed2045
# Why seed from BIP39 mnemonic phrase is much longer than entropy?

(Asked by: username_0 on 2019-04-25)

BIP39 converts mnemonic
`"zoo zoo zoo zoo zoo zoo zoo zoo zoo zoo zoo wrong"`

to the fairly long seed
`"b6a6d8921942dd9806607ebc2750416b289adea669198769f2e15ed926c3aa92bf88ece232317b4ea463e84b0fcd3b53577812ee449ccc448eb45e6f544e25b6"`

Good tool to play around <https://iancoleman.io/bip39/>

What's the point of so long seed value when the entropy value of random 12-words mnemonic is much smaller?

* 2048 words list dictionary = 2^11 => 11 bit
* 12 words \* 11 bits = 132 bit
* in hex format (4 bit for character) is 132/4=33 charter long, vs 128 of seed

**Tags:** bip32-hd-wallets, mnemonic-seed, bip


---

## 1 answers

### Answer by username_1 on 2019-04-25. Score: 5

This is specified in [BIP 39](https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki) itself:

> To create a binary seed from the mnemonic, we use the PBKDF2 function with a mnemonic sentence (in UTF-8 NFKD) used as the password and the string "mnemonic" + passphrase (again in UTF-8 NFKD) used as the salt. The iteration count is set to 2048 and HMAC-SHA512 is used as the pseudo-random function. The length of the derived key is 512 bits (= 64 bytes).

So the seed that's used is essentially a 512-bit hash of the mnemonic, which explains why it's 512 bits long (= 128 nibbles).

The BIP doesn't explain why they do this, but I would assume that it's convenient to know that the seed will always be a certain size, regardless of how much entropy is actually used to generate it. This means, for instance, that key generation code can be written to always work on 512 bit seeds.

> **Comments:**
> **username_2**: The need to have a constant size seed doesn't explain the use of PBKDF2 over say, SHA256/512 which are already used. My assumption would be that the PBKDF2 function was chosen so that in the event the mnemonic phrase is leaked, but is password protected, it is computationally less feasible to brute force passwords under PBKDF2.  

---

