<p>I doubt anyone will have such a value since it would require a tremendous amount of computation. One approach would be to monkey patch your HMAC-SHA512 function to return a value with 32 leading zero bytes for the purpose of the test.</p>

CC BY-SA 4.0
2018-06-11T11:19:36.810Z
I think you're probably correct, and this is exactly what I ended up doing, see `fakeHmacSha512Responses` https://github.com/NovaCrypto/BIP32/blob/master/src/test/java/io/github/novacrypto/bip32/ExtendedPrivateKeyEdgeCases.java
weston
CC BY-SA 4.0
2018-06-11T14:01:40.457Z
why is the sentence there if it will never happen? also, what happens if there is no "next value for i"? The last key could be invalid. If the BIP is attempting to handle all cases (even 'impossible' ones), it should handle this one too.
Janus Troelsen
CC BY-SA 4.0
2018-06-11T14:14:44.663Z
@JanusTroelsen No one said "it will never happen" (although chances are it won't). I said that probably no one has spent several PHs to calculate such a preimage to use for a unit test.
Mike D
CC BY-SA 4.0
2018-06-11T11:08:29.443Z
2018-06-11T11:08:29.443Z
Mike D
<p>I'm trying to code up <a href="https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki" rel="nofollow noreferrer">BIP0032</a>, with full test coverage and I hit a snag with these very rare edge cases:</p>
<blockquote>
<p><strong>Private parent key → private child key</strong></p>
<p>In case parse256(IL) ≥ n or ki = 0, the resulting key is invalid, and one should proceed with the next value for i. (Note: this has probability lower than 1 in 2^127.)</p>
<p><strong>Public parent key → public child key</strong></p>
<p>In case parse256(IL) ≥ n or Ki is the point at infinity, the resulting key is invalid, and one should proceed with the next value for i.</p>
</blockquote>
<p>I have not written any code around these conditions as without test cases to show I have done it correctly, it's pointless.</p>
<p>I've successfully tested my code with 30 million addresses generated from another library, but I think to stand a better than 50/50 chance of finding one of these edge cases I would have to check in the order of <code>10^19</code> (source: <a href="https://en.wikipedia.org/wiki/Birthday_attack" rel="nofollow noreferrer">Birthday attack</a>).</p>
<p>So my question is, does anyone have any test vectors for these cases?</p>
<p>The alternative is to have a whitebox test that passes bad <code>IL</code> values directly to an otherwise private function, but I'd rather have a blackbox test.</p>

<development><bip32-hd-wallets>
Edge cases for BIP32
weston
# Edge cases for BIP32

(Asked by: username_0 on 2017-11-04)

I'm trying to code up [BIP0032](https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki), with full test coverage and I hit a snag with these very rare edge cases:

> **Private parent key → private child key**
>
> In case parse256(IL) ≥ n or ki = 0, the resulting key is invalid, and one should proceed with the next value for i. (Note: this has probability lower than 1 in 2^127.)
>
> **Public parent key → public child key**
>
> In case parse256(IL) ≥ n or Ki is the point at infinity, the resulting key is invalid, and one should proceed with the next value for i.

I have not written any code around these conditions as without test cases to show I have done it correctly, it's pointless.

I've successfully tested my code with 30 million addresses generated from another library, but I think to stand a better than 50/50 chance of finding one of these edge cases I would have to check in the order of `10^19` (source: [Birthday attack](https://en.wikipedia.org/wiki/Birthday_attack)).

So my question is, does anyone have any test vectors for these cases?

The alternative is to have a whitebox test that passes bad `IL` values directly to an otherwise private function, but I'd rather have a blackbox test.

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


---

## 1 answers

### Answer by username_1 on 2018-06-11. Score: 3 | Accepted answer

I doubt anyone will have such a value since it would require a tremendous amount of computation. One approach would be to monkey patch your HMAC-SHA512 function to return a value with 32 leading zero bytes for the purpose of the test.

> **Comments:**
> **username_0**: I think you're probably correct, and this is exactly what I ended up doing, see `fakeHmacSha512Responses` https://github.com/NovaCrypto/BIP32/blob/master/src/test/java/io/github/novacrypto/bip32/ExtendedPrivateKeyEdgeCases.java  
> **username_2**: why is the sentence there if it will never happen? also, what happens if there is no "next value for i"? The last key could be invalid. If the BIP is attempting to handle all cases (even 'impossible' ones), it should handle this one too.  
> **username_1**: @username_2 No one said "it will never happen" (although chances are it won't). I said that probably no one has spent several PHs to calculate such a preimage to use for a unit test.  

---

