As far as i understood ,above line of code above can generate any value between 1 to curve.n-1 which will be private key. Can this not result in very week private key if we get the value on lower side. I am sure , i am missing something here. Can anyone help me understand this.
if we get the value on lower side
Do you mean, say if the private key is <10000?
If so, yes, that is not ideal, but, IL and kpar should both be cryptographically random.
It isn't impossible, but, there is no benefit to us constraining the range, it simply moves the lower bound.
code comment and code appears to be in mismatch. According to comment , calculate mod of _kpar_ and add to IL , but the code seems to be implemented as , adding kpar and IL together and then calculate mod of outcome.
@bit-warrior the comment is from https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki#private-parent-key--private-child-key
parse256(IL) + kpar (mod n)
My understanding is that (mod n) represents mod n over the result of the addition, not over kpar.
If it was not mod n over the result, it would support an addition result that was outside of the finite field, aka, greater than or equal to the curve order n...
Yeah, BIP32's pseudo-code is hard to read... and it doesn't help that BigInt is hard to read too... (preference lol)
Seeing as you thumbs upped the clarification, I assume this issue is resolved.
Let me know if you need it reopened.
Thanks for the clarification guys.
Most helpful comment
@bit-warrior the comment is from https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki#private-parent-key--private-child-key
My understanding is that
(mod n)representsmod nover the result of the addition, not overkpar.If it was not
mod nover the result, it would support an addition result that was outside of the finite field, aka, greater than or equal to the curve ordern...