<p>I've read about <a href="https://en.bitcoin.it/wiki/BIP_0032#Child_key_derivation_.28CKD.29_functions" rel="nofollow noreferrer">BIP32 key derivation functions</a>, and also:</p>
<blockquote>
<p>Any Elliptic Curve could work in the BIP32 scheme. The only property
of a Curve that BIP32 relies on is that a * G + b *G = (a + b mod N) *
G, which is true for any Elliptic Curve.</p>
</blockquote>
<p>(from <a href="https://bitcoin.stackexchange.com/a/48223/9323">Is BIP 32 Technology Cryptographic Curve Agnostic?</a>.)</p>
<p>Are there simpler forms of weak-child-only key derivations?  (I'm guessing that the HMAC, splitting and concatenation is unneeded for a simpler/weaker scheme.  Such a scheme would just have a large number of weak children and no layers/tree.)</p>
<p>Is a simpler scheme possible?  (I'm asking about cryptography generally, not whether it's a good idea for Bitcoin.)</p>

CC BY-SA 4.0
2020-07-03T16:10:27.823Z
`SHA256(entropy | index)`. 1st key = `SHA256(entropy | 0x00000000)`, 2nd key = `SHA256(entropy | 0x00000001)`,...
Coding Enthusiast
CC BY-SA 4.0
2020-07-04T06:10:15.313Z
@CodingEnthusiast Could you expand that into an answer, please?  I can't understand how these keys relate to the parent keys, as they do not depend on them at all.  In particular I want to derive child public keys from just a parent public key, knowing that the owner of the parent private key can derive the associated child private keys.
fadedbee
CC BY-SA 4.0
2020-07-04T08:35:16.700Z
It is a **very very weak** way of deriving child _private_ keys from an initial entropy. If deriving pubkey in a _weak_ way is desired then a similar scheme to BIP-32 for non-hardened children could be used to compute `SHA256(parentPubKey | index)` where child _private_ key is the `parent+child % N`
Coding Enthusiast
CC BY-SA 4.0
2020-07-04T08:47:50.890Z
Is `parentPrivKey+index % N` the private key for `parentPubKey | index`?  (I cannot see how the unreversable SHA256 can help here at all, but that may well be my lack of knowledge.)
fadedbee
<bip32-hd-wallets><secp256k1>
Is there a simpler form of BIP32-like key derivation?
fadedbee
# Is there a simpler form of BIP32-like key derivation?

(Asked by: username_0 on 2020-07-03)

I've read about [BIP32 key derivation functions](https://en.bitcoin.it/wiki/BIP_0032#Child_key_derivation_.28CKD.29_functions), and also:

> Any Elliptic Curve could work in the BIP32 scheme. The only property
> of a Curve that BIP32 relies on is that a \* G + b \*G = (a + b mod N) \*
> G, which is true for any Elliptic Curve.

(from [Is BIP 32 Technology Cryptographic Curve Agnostic?](https://bitcoin.stackexchange.com/a/48223/9323).)

Are there simpler forms of weak-child-only key derivations? (I'm guessing that the HMAC, splitting and concatenation is unneeded for a simpler/weaker scheme. Such a scheme would just have a large number of weak children and no layers/tree.)

Is a simpler scheme possible? (I'm asking about cryptography generally, not whether it's a good idea for Bitcoin.)

**Tags:** bip32-hd-wallets, secp256k1

> **Comments:**
> **username_1**: `SHA256(entropy | index)`. 1st key = `SHA256(entropy | 0x00000000)`, 2nd key = `SHA256(entropy | 0x00000001)`,...  
> **username_0**: @CodingEnthusiast Could you expand that into an answer, please?  I can't understand how these keys relate to the parent keys, as they do not depend on them at all.  In particular I want to derive child public keys from just a parent public key, knowing that the owner of the parent private key can derive the associated child private keys.  
> **username_1**: It is a **very very weak** way of deriving child _private_ keys from an initial entropy. If deriving pubkey in a _weak_ way is desired then a similar scheme to BIP-32 for non-hardened children could be used to compute `SHA256(parentPubKey | index)` where child _private_ key is the `parent+child % N`  
> **username_0**: Is `parentPrivKey+index % N` the private key for `parentPubKey | index`?  (I cannot see how the unreversable SHA256 can help here at all, but that may well be my lack of knowledge.)  

---

## 0 answers

