# Consequences of sibling keys when xpub and xprv are leaked

Let's say the following keys are leaked:

• 44'/60'/4'/0 extended private key
• 44'/60'/4'/0 extended public key (you can just derive this from the above private key)

Now using the above information can we derive the private or public key of this path:

44'/60'/4'/1

I don't think we can derive the private key because to get the private or public key of 44'/60'/4'/1, we need to know the private key or public key for the path `44'/60'/4'`. But that's not something which we can calculate from the above information. Is my understanding right ?

You have interpreted that correctly. If your child extended private key belonging to path `m/44'/60'/4'/0` is leaked, the attacker cannot figure out the child extended private key from path `m/44'/60'/4'/1`.
The non-hardened derivation for child private key is `kchild = kpar + hash(Kpar, cpar, i)`. Here `k` represents private key, `K` is the public key, `c` is the chain code and `i` is the index number. If you note, the index number sits inside the hash function in the child key derivation. Since hash functions are undeterministic, slight change in its input can have a very different effect on the output. Hence incrementing the index number `i` from 0 to 1 will yield completely different result and hence cannot be back-calculated.
• @Sibi BIP 44 key derivation has the path m / purpose' / coin_type' / account' / change / address_index. If you check the `xprv` you mentioned, you are using BIP 44, so purpose is 44'. `coin_type` is 60' so that is ETH. `account` is 4' so that is the 5th account. you can increment index at the account level and generate number of different accounts from which you can then generate receiving and change addresses. Users can use accounts to organize funds in same way as bank accounts; for donation purposes (where all addresses are considered public), for saving purposes, for common expenses etc. – Ugam Kamat Sep 26 '19 at 5:43