How are children's private keys in HD wallets obtained and how can knowing them reveal the parent's private key?

Question

I'm reading master bitcoin book and I came to the part related to HD wallets and how to create a Child private key (link). It says the following:

The parent public key, chain code, and the index number are combined and hashed with the HMAC-SHA512 algorithm to produce a 512-bit hash. This 512-bit hash is split into two 256-bit halves. The right-half 256 bits of the hash output become the chain code for the child. The left-half 256 bits of the hash are added to the parent key to produce the child private key. In Extending a parent private key to create a child private key, we see this illustrated with the index set to 0 to produce the "zero" (first by index) child of the parent.

The bolded sentence causes me misunderstanding. What type of addition is this? If the classical addition of the left 256 bits of the hash result to the private key of the parent is implemented, then it will lead to a 512-bit private key of the child, which is not correct (the private key should be 256-bit). Is this perhaps referring to addition in the context of the "logical and" between the left hash result and the parent's private key? What type of addition is meant here when the result should be 256-bit? Some answer is given here, but I'm still not clear. The answer is related to the use of modules.

What further confuses me is that the book says that if the child's private key is known, the parent's private key can be determined? That would make perfect sense to me if it was about adding the left half of the hash to the parent's private key. You simply remove the part related to the hash from the 512-bit result and get parent's private key. However, how can it be done here?

Answer 1

If the classical addition of the left 256 bits of the hash result to the private key of the parent is implemented, then it will lead to a 512-bit private key of the child, which is not correct (the private key should be 256-bit).

As Michael Folkson explains in that answer you linked:

There is concatenation where 256 bits placed next to another 256 bits makes 512 bits. However, what you are referring to is scalar addition. A 256 bit number (256 bit parent private key) is added to another 256 bit number (left 256 bits of the SHA512) and the result modulo p (p = 2^256-2^32-977) is another 256 bit number.

It in some sense will behave like classical addition (before the modulo operation).

Although I am not 100% sure where p is specifically defined, the modulo p operation where p = 2^256-2^32-977 is the relevant operation that will shorten the resulting key to 256 bit. (because p is a 256 bit number)

So you add the left 256 bits to the parent private key to get the ( large 512 bit ) child private key, then you modulo p to shorten the result to 256 bit.

Okay, let's say you and Michael are right. How will the parent's private key be obtained knowing the child's private key? If the module's operations are really used to obtain a 256-bit key, then inversion and obtaining the parent's private key cannot be performed at all... In the book, they say that it is "relatively easy" to obtain the parent's private key from knowing the child's private key.

This was discussed partially here Xpriv can be calculated from the xpub + child private key?

according to: https://medium.com/@blainemalone01/hd-wallets-why-hardened-derivation-matters-89efcdc71671#cc82

the equation for deriving the parent key from child is:

child private key = (left 32 bytes + parent private key) % n

Bob solves for parent private key:

parent private key = (child private key - left 32 bytes) % n

Note here we are using modulo n which is the Secp256k1 curve order, this is a common operation in ECC. It is possible Michael meant modulo n but I cannot confirm this.

The same formula you provided is also mentioned here. But here they use G instead of n. I know that G is a generic point (a point on an elliptic curve) used to generate a public key from a private key. So is n actually G?)

In this section you will notice p is being used and is explained to be a global constant in Bitcoin software but nothing more is said about it: https://developer.bitcoin.org/devguide/wallets.html#hierarchical-deterministic-key-creation

This section G is being used: https://developer.bitcoin.org/devguide/wallets.html#id5

I know for certain G is used to derive public from private keys through scalar multiplication.

I do not want to state any incorrect facts about the utilization of these values, my opinion is that in this circumstance it makes more sense that the modulo operation is done via n because of this article that seems to detail it extremely well but since I don't know for certain I can only attempt to provide researched context.

Answer 2

What follows contains inaccurate notation and language on purpose, in order to make the conceptual explanation lighter and more straightforward.

---

A BIP32 extended private ("xprv") or public ("xpub") key is composed of two parts: the key itself and the chaincode. The key is either the private key k (for an xprv) or the public key K (for an xpub). The chaincode is a 256 bits integer, identical for both the private and public versions.

BIP32 defines the CKD_priv((k_par, c_par), i) → (k_i, c_i) function that derives a child extended private key from a parent extended private key at a given index i. (k_par, c_par) are the private key and the chaincode of the parent, and (k_i, c_i) the private key and the chaincode of the child at index i. Let's call K_par the public key corresponding to k_par.

For unhardened derivation (i < 2^31), CKD_priv is defined as (loosely speaking):

• let I = HMAC-SHA512(Key = c_par, Data = K_par || i). (With all data serialized as bytes.)
• c_i is the rightmost 32 bytes of I.
• k_i is the leftmost 32 bytes of I (as an integer), added to k_par.

The insight in the above is that you can get I without knowing any secret: this makes sense, in some cases you may want an entity (such as an online server) to be able to derive public keys without having access to any secret. But this opens up the possibility to compute k_par from (K_par, c_par) and k_i, or in other words to compute the parent's xprv from the parent's xpub and any child private key (along with its index):

1. From the parent's (K_par, c_par) and the index i, compute I.
2. Let I_L be the leftmost 32 bytes of I.
3. Compute k_par by substracting I_L from k_i.

---

Note by using hardened derivation, it's not possible to compute I_L without the parent private key. This makes it impossible to use the above trick to get the parent private key from the child private key and parent extended key, at the cost of making it impossible to derive public keys without knowledge of the parent private key.

More on the security of BIP32 here.