PrivateKey.fromWif not support compressed WIF format

[zhjjj]

It seems that PrivateKey.fromWif doesn't support WIF with compressed format.
When I use a WIF private key with compressed format, some warning shows up:
WARN: Expecting 32 bytes, instead got 33, stack trace: Error
And I can get a result from the function. However, the result is not correct.

So I read the souce code. PrivateKey.fromWif will generate a BigInteger from buffer generated from WIF format. So if I provide a compressed WIF which has an extra compressed flag byte, it will use the 33 bytes data to generate the private key. But it is not my original private key.

[jcalfee]

I see what your talking about in the Bitcoin spec.. I'll look into it.

[jcalfee]

So far, we have used WIFs and compressed "public keys" without adding this 0x01 byte on the end of the private key WIF. This "compressed" flag applies to the public key though (not the private key). It seems to be more like a friendly / helpful indicator (to the best of my knowledge).

The 0x01 compression flag is under the checksum and the length is of the private key matches so I think it is safe to remove this and create the correct private key. It is reasonable that a library would create a WIF and add this 0x01 compression flag, this is just a change in how keys are being created in the libraries so far.

@chris-allnutt what do you think: I can just remove and ignore this compression byte if i see it (no warning no error).

[jcalfee]

published eosjs-ecc@4.0.1

[RayMetz100]

Three BP key checker tools accepted compressed K/L private keys and gave a consistent private key with this 0x01 bug that didn't match the registered public key after EOS launch. When I enter my same prelaunch private key to cleos now, it gives me a different public key and my funds are stranded on the registered public key.

Was this 0x01 issue applied before or after the SHA256 hash? If it was applied before, then it may be possible to take my private key and convert it to a different private key that will match the patched software. If the extra byte issue was after the hash, then there's no way to create a matching private key and the public key is a burn address. which side of the SHA256 hash is this bug on?

[jcalfee]

This change is very safe. It allowed additional valid private keys (more spec like) to get parsed. There is no burn address possible.

[RayMetz100]

I have four compressed private keys I generated with iancoleman/bip39. I put them in the pre-launch key checker tools and had the tools hash me matching public keys. I registered the public keys with 170 eos. Pre launch. Today I can still put my same private keys into the key checker tools and generate the same matching public keys that I registered, because the key checkers still have the 0x01 bug. I can see the migrated EOS balance now on those registered public keys.

Because I generated public keys having the bug, and cleos does not have the bug, when I put my same compressed private keys into cleos, I get different public keys and no access to my funds.

Is there a way to convert my four private keys to patched private keys that can be entered into cleos and hash to my registered public keys?

Repro steps... Generate any test compressed private key with leading K or L. Put it into any key checker tool and generate a matching bugged public key. Transform the private key somehow to adjust for the 0x01 bug. Enter the revised private key into cleos. Cleos gives the matching public key that the bugged key checkers did.

How can I transform my private keys to get around the bug?

[jcalfee]

Do you have a web tool for this?

Generate any test compressed private key with leading K or L.

Please tell me which one your using:

Put it into any key checker tool and generate a matching bugged public key.

[RayMetz100]

All of these still have the same bug
https://github.com/eoscafe/eos-key or https://github.com/webdigi/EOS-Offline-Private-key-check or https://github.com/eosamsterdam/eos-keypair-check

This will give you lots of test private keys with leading K or L. Try importing them into cleos and the key checker tools above to see the different public keys generated for the same private keys. https://iancoleman.io/bip39/?

If you want to convert the same private key to compressed leading K or L vs. uncompressed leading 5 use bit address.org and choose "Wallet Details" option.

Example:
https://www.bitaddress.org/bitaddress.org-v3.3.0-SHA256-dec17c07685e1870960903d8f58090475b25af946fe95a734f88408cef4aa194.html

[jcalfee]

Thanks for the links .. I am just looking for 1 case.. All private keys start with "5" .. I'm not sure what your saying.. This one gives some test keys but it imports and converts just fine:

https://github.com/webdigi/EOS-Offline-Private-key-check

$ 5JS9bTWMc52HWmMC8v58hdfePTxPV5dd5fcxq92xUzbfmafeeRo
$ cleos wallet import -n pkcheck
private key: imported private key for: EOS8HuvjfQeUS7tMdHPPrkTFMnEP7nr6oivvuJyNcvW9Sx5MxJSkZ