Why is HMAC-SHA512 used on root the root seed to create master private key and chain code in HD wallets?

Question

The process is depicted in this picture. Specifically, given that the root seed was derived using PBKDF2 (with 2048 rounds of hashing with HMAC-SHA256 already), why do we undergo an additional pass of HMAC-SHA512, besides for creating 512 bits of entropy? Why not just use SHA512 alone? I've asked here before and the answer I got was that the HMAC version is used to ensure unique generation of the key, but I don't know what that means. It seems for derivation of the master private key and chain node, the function is being used as a one-way hash function only, so why is a MAC being used? There is a single thing being encrypted, we are not additionally trying to guarantee authenticity on anything here, right?

Answer 1

Specifically, given that the root seed was derived using PBKDF2 (with 2048 rounds of hashing with HMAC-SHA256 already), why do we undergo

and

an additional pass of HMAC-SHA512, besides for creating 512 bits of entropy?

Those things come from different standards. BIP32 (which specifies going from masterkey to keys) came first. Various ways for constructing master keys/seeds are in use that came later; I assume you're referring to one of those.

Answer 2

Why not just use SHA512 alone?

I'm not sure. I think that would work fine. The only tricky detail would be that you need include the passphrase, too.

It seems for derivation of the master private key and chain node, the function is being used as a one-way hash function only,

To be entirely accurate, you need more than a one-way function. For example, if the hash function always produced a hash that was divisible by 3, that would follow all of the properties of the hash function, but it would be weaker as a key derivation function.

Answer 3

I'm willing to bet the 2048 rounds of hashing required by the BIP 39 Standard takes considerably more energy than 1 round of hashing.

Put another way, substantial computing cycles are required to create brute forced Rainbow Tables when lower entropy human readable seeds are functionally mapped to private keys. This is somewhat analogous to the leading hash zeroes values miners satisfy to add blocks to a PoW-based blockchain, except the computing cylces are fixed by mnemonics-to-seed portion of the BIP39 Standard.

The Python stretch can effectively implement the mnemonics-to-seed functionality written into BIP 39.

stretch->passlib.pbkdf2(secret, “mnemonic”+salt, rounds=2048, keylength=64, sha512)

The two two Bitcoin-related examples of piped commands using stretch and bx yield the same result.

% stretch -f sha512 -r 2048 "bunker wreck real edge inflict aerobic buddy mercy divorce wolf bright immune fat foot poet section sustain reveal unique reflect have latin problem chapter" mnemonic123 | bx base64-decode | bx base16-encode | bx hd-new | bx hd-private xprv9veSXAfA7GoYvaMAXgm3uYGS4VLH1Foc9qmTBRCb4c3F2Vqd261k2vo646nLU54MRVseFx2BbhZYQS9HDUy4dvTV3fygVGxedqYSR82B3he

% echo "bunker wreck real edge inflict aerobic buddy mercy divorce wolf bright immune fat foot poet section sustain reveal unique reflect have latin problem chapter" | bx mnemonic-to-seed -p 123 | bx hd-new -v 76066276 | bx hd-private xprv9veSXAfA7GoYvaMAXgm3uYGS4VLH1Foc9qmTBRCb4c3F2Vqd261k2vo646nLU54MRVseFx2BbhZYQS9HDUy4dvTV3fygVGxedqYSR82B3he