Purpose of "hardened key" in BIP32?

[DeathAndTaxes]

What is the purpose of "hardened key" in BIP32? The BIP seems to talk around the concept without actually addressing the reason for using a hardened key over a normal (non-hardened) key.

We represent an extended private key as (k, c), with k the normal private key, and c the chain code. An extended public key is represented as (K, c), with K = point(k) and c the chain code.

Each extended key has 2^31 normal child keys, and 2^31 hardened child keys. Each of these child keys has an index. The normal child keys use indices 0 through 2^31-1. The hardened child keys use indices 2^31 through 2^32-1. To ease notation for hardened key indices, a number iH represents i+2^31.

Ok so using an index > 2,147,483,647 results in a hardened key otherwise it is a normal key.

Given a parent extended key and an index i, it is possible to compute the corresponding child extended key. The algorithm to do so depends on whether the child is a hardened key or not (or, equivalently, whether i ≥ 231), and whether we're talking about private or public keys.

...
The function CKDpub((Kpar, cpar), i) → (Ki, ci) computes a child extended public key from the parent extended public key. It is only defined for non-hardened child keys.

So hardened keys (which are defined as a child [private]Key produced from an index > 2^31-1) can not be derived from the parent's extendedPubKey.  Is the reason for "hardening" a key to prevent recomputation of the parent's extended[Private]Key (and thus all derived [private]Keys) in the event of the accidental disclosure of a)parent's extendedPubKey AND b) any private key that is a child of that parent?  Beyond that key leakage scenario is there any risk or limitation of using normal (non-hardened) keys over hardened ones?

The reason I ask is because an obvious usage of BIP32 is to create a "watching wallet".  A server which is processing incoming payments would only need the extendedPubKey and an indexer.  With just those elements (and no [private]Key) the server could deterministically create a number of PubKeys as needed.  The obvious advantage is the server has no knowledge of the extended[Private]Key for security reasons. Am I correct to assume this isn't possible to with hardened keys?

If the prior two assumptions are correct then I am going to infer that the rationale for using hardened keys is to gain added security in a scenario where the extended[Private]Key is present and thus there is no need to use/share the extendedPubKey.  An example would be internal usage by a desktop wallet for computing change addresses.  The wallet can derive PubKeys indirectly from the derived [private]Keys.  Is this a correct assumption?

As a recommendation for the BIP32 document, it may be useful to early on define normal vs hardened keys and articulate a rationale for selecting one over the other.

[1714753676]

1714753676

[1714753676]

1714753676

[1714753676]

1714753676

[Abdussamad]

So hardened keys (which are defined as a child [private]Key produced from an index > 2^31-1) can not be derived from the parent's extendedPubKey.  Is the reason for "hardening" a key to prevent recomputation of the parent's extended[Private]Key (and thus all derived [private]Keys) in the event of the accidental disclosure of a)parent's extendedPubKey AND b) any private key that is a child of that parent?

Yes.

The obvious advantage is the server has no knowledge of the extended[Private]Key for security reasons. Am I correct to assume this isn't possible to with hardened keys?

Yes.

The idea is that first level of keys from the master key are hardened ones and subsequent levels are the normal ones. This allows you to protect the master private key and get deterministic address generation using extended public keys too (from third level onwards).

edit: see the info here:

Private wallet keys have one additional power over public keys: only private wallet keys can generate children that use the “prime” directive. This derivation requires information about the secret exponent, which is stripped out of public keys

http://blog.richardkiss.com/?p=313

[giszmo]

Old post but I can't see the topic being explained anywhere near enough. It should be stated in the BIP32 itself.

At http://blog.richardkiss.com/?p=313&cpage=1#comment-93828 Peter Wuille says:

Not only revealing an xprv serialized key reveals the entire chain under it. Having an xpub plus any private key beneath it does that too (unless you use prime derivation, which is why it exists).

I had heard that with HD-Wallets, knowing any one xpub key and any one private key for a public key in the xpub key's chain would result in the chain being revealed up and down.

So what would I want non-prime keys for? Wouldn't it make sense then to define derivation to be limited to the prime space rather than to default to non-prime for small numbers?

Again, did I understand right?

Given this example using bitcore …

Code:

var HD = HDPrivateKey()
var hardened = HD.derive("m/5/5'/5/5")
var simple = HD.derive("m/6/6/6/6")
console.log(hardened.xpubkey)
// [1] output is "xpub6EP1wojrFHh7yDe2pbxiMCbdcyGfvv8eJEt28WYL1v14inWKMzss988YQSHU4KpsAkTEFW6dUGbE9LysJXTJzGHFMLFApoHBK6sntTvjxUC"
console.log(hardened.derive(1000).privateKey.toString())
// [2] output is "f0d658dc1b186862fac071bf280a38ab20d28dffe7843900e899cde2e9c01077"
console.log(simple.xpubkey)
// [3] output is "xpub6EohLkw7QkEdFTdsNg7Jeho4ywsf2CvQBHnBbaenTofnSg2JG5BiBzVo1Bm6L1ru5D5jLuDX71YACig1e2QNeJvy39SKYUEcafYNvegMYon"
console.log(simple.derive(1000).privateKey.toString())
// [4] output is "8b0a7eee9f4220dcda06d048520b0cc1a600b3d52963c84ca2b02434348f84ce"
console.log(simple.privateKey.toString())
// [5] output is "b284d9bdc4a798455dc2c4eb9805376b292d57853e4884f0840c03cb581e609e"

At 1 you would learn the xpubkey m/5/5'/5/5 and all its children but no private key.

At 2 you would learn all the xpubkeys and xprivkeys derived from m/5/5'.

At 3 you would learn all the xpubkey m/6/6/6/6 and all its children but no private key.

At 4 you would learn m and all its children including private keys.

There is no need for 5.