Fix bug that assumes toByteArrayUnsigned() always returns 32 bytes. #5
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
To reproduce this bug, try entering the following XPRIV: xprv9s21ZrQH143K3GMYVMZBZCGProVPNqGXRXz3ktUYt1rXG813HhysPLeNj8AfahpW2d4Tc678FMYndMrw9sqUFuLD2mug9pwojMuNusRbsv9 and use the following derivation path: m/44' The correct derived private key should be: xprv9tzN9JZpuT1wiz7y2qsBnjttAxvUQcdjCCEVXdMQmp32FeX4vGve5PA7yFan15Jo71HrxsA6VAnpqWW2JNoaXaLe3NeqWKoYS76AEBfioN7 but the code was previously outputting: DeaWiSNc9gKmPJgBaytskvDH3Cz4tebKSjxu9t2hSyGVx1gt2xdGPVXjPHoUQd9LBRpcJQDbFdQdEAzqWq2eVeErNLsGwEEWGEGgArZjHap4aP This was as a result of line 185 in bip32.js calling this.eckey.priv.toByteArrayUnsigned() without verifying that the returned byte array had the correct length required for serialization (32 bytes). Furthermore, errors would cascade down the path dangerously unnoticed. For example, using the path m/44'/0' with the XPRIV mentioned above, the correct derived private key should be: xprv9xUGaEZ5EBM1tGE9Ujp2EaPC85Pt8PRwMSmk53rvy3YmJbg6jBZM3mybraxFBWFgzrfhEhiiugDMArUqiGDSQF3zHL8wY6AZBXE77Jq2utJ however the original code would give: xprv9xUGaEZ5EBM1ueG3H1yNEgQuk9ivpzaHhVbp58hcCJSyrinvZC3k6uvzobs6Av5UmLvjfRQK6AWq2fL9ej27wjr3BURJFddYzvovFYngqLS This was quite dangerous as there is nothing obviously wrong with the output. This cascading bug was due to line 254 in bip32.js which also incorrectly assumed that toByteArrayUnsigned() always returns a 32 byte long array.
|
This solves issue #4 |
sarchar
added a commit
that referenced
this pull request
Oct 30, 2014
Fix bug that assumes toByteArrayUnsigned() always returns 32 bytes.
|
Merged. Thanks for the commit. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
To reproduce this bug, try entering the following XPRIV:
xprv9s21ZrQH143K3GMYVMZBZCGProVPNqGXRXz3ktUYt1rXG813HhysPLeNj8AfahpW2d4Tc678FMYndMrw9sqUFuLD2mug9pwojMuNusRbsv9and use the following derivation path:
m/44'The correct derived private key should be:
xprv9tzN9JZpuT1wiz7y2qsBnjttAxvUQcdjCCEVXdMQmp32FeX4vGve5PA7yFan15Jo71HrxsA6VAnpqWW2JNoaXaLe3NeqWKoYS76AEBfioN7but the code was previously outputting:
DeaWiSNc9gKmPJgBaytskvDH3Cz4tebKSjxu9t2hSyGVx1gt2xdGPVXjPHoUQd9LBRpcJQDbFdQdEAzqWq2eVeErNLsGwEEWGEGgArZjHap4aPThis was as a result of line 185 in bip32.js calling
this.eckey.priv.toByteArrayUnsigned()without verifying that thereturned byte array had the correct length required for serialization
(32 bytes).
Furthermore, errors would cascade down the path dangerously unnoticed.
For example, using the path
m/44'/0'with the XPRIV mentioned above,the correct derived private key should be:
xprv9xUGaEZ5EBM1tGE9Ujp2EaPC85Pt8PRwMSmk53rvy3YmJbg6jBZM3mybraxFBWFgzrfhEhiiugDMArUqiGDSQF3zHL8wY6AZBXE77Jq2utJhowever the original code would give:
xprv9xUGaEZ5EBM1ueG3H1yNEgQuk9ivpzaHhVbp58hcCJSyrinvZC3k6uvzobs6Av5UmLvjfRQK6AWq2fL9ej27wjr3BURJFddYzvovFYngqLSThis was quite dangerous as there is nothing obviously wrong with the
output. This cascading bug was due to line 254 in bip32.js which also
incorrectly assumed that toByteArrayUnsigned() always returns a 32 byte
long array.