<p>It is because the root seed may not be 512 bits, it could be 128 bits or 256 bits for example as seen in the picture you linked. Thus the final SHA-512 is applied to the seed so that no matter what the seed is, 512 bits will always be generated.</p>

<p>The seed generation described in BIP 39 is independent of the seed -> extended private key step in BIP 32. I expect BIP 32 uses HMAC-SHA-512 instead of just SHA-512 because it makes no assumptions about how the seed was generated, and wants to ensure that the extended private key is uniquely generated for BIP 32 use rather than just using any old SHA-512 hash that could have come from elsewhere.</p>

CC BY-SA 3.0
2017-10-19T08:36:17.613Z
But why HMAC-SHA-512 as opposed to a regular SHA-512 hash? Was this just arbitrary since it was used before?
Leeren
CC BY-SA 3.0
2017-10-19T09:32:41.520Z
Ah sorry I misread your question. I've updated my answer :)
meshcollider
CC BY-SA 3.0
2017-10-19T15:53:00.100Z
Can you explain why HMAC-SHA-512 makes no assumptions on how the seed was generated but SHA does?
Leeren
CC BY-SA 3.0
2017-10-19T20:00:43.747Z
Simply mean we want a key generated from the seed specifically for this purpose, rather than any old SHA-512 hash
meshcollider
CC BY-SA 3.0
2017-10-19T08:16:10.023Z
2017-10-19T09:32:34.700Z
2017-10-19T09:32:34.700Z
meshcollider
<p>From what I understand, the wallet seed is created by inputting into PBKDF2 (using HMAC-SHA512 of which 2048 rounds are applied) a bunch of mnemonic code words and an optional salt (defaulted to "mnemonic").  This generates a 512 bit-seed that is completely impractical to brute-force. This is a <a href="https://github.com/bitcoinbook/bitcoinbook/raw/second_edition/images/mbc2_0509.png" rel="nofollow noreferrer">picture</a> of the process that I am referring to taken from Mastering Bitcoin. Why, then, is it again hashed using HMAC-SHA512, besides for creating 512 bits of output (in the case where it originally might have been 128 or 256)? Why not just use a SHA512 hash alone (assuming the reason is just to create 512 bits)? What is the point of the HMAC here? Length-extension attacks should have been avoided from the previous iterations during PBKDF2, no? </p>

<wallet><bip32-hd-wallets>
Why is the root seed of an HD wallet undergo an additional HMAC-SHA512 hash to generate the master private key and master chain code?
Leeren
# Why is the root seed of an HD wallet undergo an additional HMAC-SHA512 hash to generate the master private key and master chain code?

(Asked by: username_0 on 2017-10-19)

From what I understand, the wallet seed is created by inputting into PBKDF2 (using HMAC-SHA512 of which 2048 rounds are applied) a bunch of mnemonic code words and an optional salt (defaulted to "mnemonic"). This generates a 512 bit-seed that is completely impractical to brute-force. This is a [picture](https://github.com/bitcoinbook/bitcoinbook/raw/second_edition/images/mbc2_0509.png) of the process that I am referring to taken from Mastering Bitcoin. Why, then, is it again hashed using HMAC-SHA512, besides for creating 512 bits of output (in the case where it originally might have been 128 or 256)? Why not just use a SHA512 hash alone (assuming the reason is just to create 512 bits)? What is the point of the HMAC here? Length-extension attacks should have been avoided from the previous iterations during PBKDF2, no?

**Tags:** wallet, bip32-hd-wallets


---

## 1 answers

### Answer by username_1 on 2017-10-19. Score: 1 | Accepted answer

It is because the root seed may not be 512 bits, it could be 128 bits or 256 bits for example as seen in the picture you linked. Thus the final SHA-512 is applied to the seed so that no matter what the seed is, 512 bits will always be generated.

The seed generation described in BIP 39 is independent of the seed -> extended private key step in BIP 32. I expect BIP 32 uses HMAC-SHA-512 instead of just SHA-512 because it makes no assumptions about how the seed was generated, and wants to ensure that the extended private key is uniquely generated for BIP 32 use rather than just using any old SHA-512 hash that could have come from elsewhere.

> **Comments:**
> **username_0**: But why HMAC-SHA-512 as opposed to a regular SHA-512 hash? Was this just arbitrary since it was used before?  
> **username_1**: Ah sorry I misread your question. I've updated my answer :)  
> **username_0**: Can you explain why HMAC-SHA-512 makes no assumptions on how the seed was generated but SHA does?  
> **username_1**: Simply mean we want a key generated from the seed specifically for this purpose, rather than any old SHA-512 hash  

---

