Closed ar-conmit closed 2 years ago
@ar-conmit Thanks for such a well documented issue. I didn't even consider that we may be only returning 31 bytes instead of 32. Since you've already put in the work to figure out what the fix should be perhaps making a PR and getting credit for it would make sense? If no that's completely fine too.
Description
There are cases when the generated ECDSA private keys are with different lengths.
The full private key(with DER header) is generated fine. The raw private key sometime is 31-bytes long.
Example:
3030020100300706052b8104000a04220420a5c09853a1628353f4bd0eb6acf5d89c3a90fc2a9dc2caf44c9aabdf96640b00
a5c09853a1628353f4bd0eb6acf5d89c3a90fc2a9dc2caf44c9aabdf96640b
It seems the raw key is not extracted successfully, the last
00
are missing. This behaviour is observed once in a while.If the full key is provided to the SDK, the raw key is extracted successfully:
PrivateKey.fromStringECDSA('3030020100300706052b8104000a04220420a5c09853a1628353f4bd0eb6acf5d89c3a90fc2a9dc2caf44c9aabdf96640b00').toStringRaw()
->
a5c09853a1628353f4bd0eb6acf5d89c3a90fc2a9dc2caf44c9aabdf96640b00
The issue occurs only in the generation process
Steps to reproduce
Once in n times the generated raw key will be 31 bytes long
after some time, the following response will be printed out
Additional context
The following change seems to fix the issue
in cryptography/ECDSAPrivateKey.js file
to be
Hedera network
other
Version
2.17.0
Operating system
macOS