What is the maths behind Bitcoin's BIP32?

Question

I've read about BIP32 key derivation functions.

I'm trying to understand how, given a secp256k1 key pair, that "child" public keys may be generated from just the public key, and the corresponding child private keys can be generated from the private key.

It seems to me (and I'm probably mistaken) that the HMAC-SHA512 and concatenation is not important, and that there is a simpler way of making child keys from just the appropriate type of parent key.

Is BIP32 as simple as it can be for the case of non-hardened child keys?

Or are there functions which just depend on a child-number, i, and the parent key of the appropriate type, to generate child keys?

Answer 1

It seems to me (and I'm probably mistaken) that the HMAC-SHA512 and concatenation is not important, and that there is a simpler way of making child keys from just the appropriate type of parent key.

Yes you are mistaken - the trick definitely lies in the HMAC (or similar) one way function that protects the parent keys. This is also where the "chain code" comes at play, since it protects the parent keys with the HMAC (or similar).

Or are there functions which just depend on a child-number, i, and the parent key of the appropriate type, to generate child keys?

There are but they are not considered safe - imagine putting sha256(parentPivateKey || i) to the public where i is known and the length of your parentPivateKey is known, that could be attacked in a lot of ways.

PS: Instead of "child-number" you meant probably a child identifier