Skip to content

Reject a private-key hex string with a non-hex digit - #473

Merged
aharoitx merged 2 commits into
bitpay:10.3.xfrom
SashaMIT:codered-hex-key
Oct 9, 2026
Merged

aharoitx merged 2 commits into
bitpay:10.3.xfrom
SashaMIT:codered-hex-key

Conversation

@SashaMIT

Copy link
Copy Markdown
Contributor

Summary

  • hexToBytes throws when the length is odd, and it accepts any other character.
  • hexToBytes("0G") returned. G is not a hex digit. The nibble math maps it to 16, so 0G decodes to the same byte as 10.
  • A non-hex digit now throws BitPayGenericException. 0123456789abcdef still decodes.

Test plan

  • On tip, it_should_reject_a_non_hex_key_digit expected BitPayGenericException and nothing was thrown
  • After the change, mvn -Dtest=KeyUtilsTest test is 6 tests, 0 failures

Made with Cursor

hexToBytes already rejects an odd length, but 0G still decoded to the same byte as 10.
@aharoitx

aharoitx commented Oct 9, 2026

Copy link
Copy Markdown
Contributor

Thanks for the fix, Sasha.

I checked it: on the current code "0G" decodes to the same byte as "10", so a bad key turns into a different key without any error. Your test fails on 10.3.x and passes with the change. It also matches what the C# SDK already does.

Tests and checkstyle pass on Java 8. I'll fix the small import conflict with 10.3.x and merge after CI passes.

@aharoitx
aharoitx merged commit 8aba42d into bitpay:10.3.x Oct 9, 2026
@SashaMIT

Copy link
Copy Markdown
Contributor Author

Thanks for checking it on 10.3.x and for merging it. A bad hex digit was becoming a different key, and rejecting it matches the C# SDK.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants