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.