Bitcoin Private Key bug

[RayMetz100]

Repro steps: Go to https://www.bitaddress.org or any bitcoin tool and generate any bitcoin private key

Go to https://github.com/eoscafe/eos-key or https://github.com/webdigi/EOS-Offline-Private-key-check or https://github.com/eosamsterdam/eos-keypair-check , Copy in the private key and view the matching public key. Notice the public keys generated from all three tools match.

Use cleos wallet import command to import the same private key. Notice the public key from cleos doesn't match the tools.

Why don't the BP tool public keys match cleos?

When I start with an EOS private key rather than BTC private key, the tools match cleos wallet import.

I know people are going to say the bug/feature is because I started with a bitcoin private key and not an EOS private key. Any insight beyond that?

As long as I avoid using the BP key checker tools, it seems perfectly ok to use a Bitcoin generated private key and cleos wallet import command to get a matching and working public key. There are no problems with the public key generated by cleos wallet import. It's only the BP tools that generate bad public keys. Why?

Ref: https://www.reddit.com/r/eos/comments/8so7ef/bp_key_checkers_have_a_bug/ https://www.reddit.com/r/eos/comments/8qzcwa/seems_like_i_lost_170_eos/

[firmwareguru]

@RayMetz100 I am unable to reproduce this. Do you have any key pair examples you can provide that exhibit this behavior?

[RayMetz100]

see: https://github.com/EOSIO/eos/issues/4838

`Repro steps:

1. Download eos-key-win32-x64.zip from https://github.com/eoscafe/eos-key/releases

2. Unzip to eos-key-win32-x64 folder

3. Open eos-key.exe File version is 1.1.0.0, opens as "Offline EOS Keys Generator"

4. generate a Bitcoin compatible private key using https://iancoleman.io/bip39/ My example was Kx9c3uvybEkFuMkckocfW7kzKsju3vquSpT51UamXatJSMiqNmhX

5. Copy/Paste Bitcoin private key into Offline EOS Keys Generator, "Find Public Key" field and click "Find". My example gave EOS7hweQQgQrRXJ2jewoxohp4z3JF9HWa3wJyrFY9ksvZB7M83BSv

6. For good measure, paste same keys into "Validate Key Pair" section and click "Validate". They validate.

7. install eos git clone https://github.com/EOSIO/eos --recursive ./eosio_build.sh

8. create a new wallet with: cleos wallet create (if you get the keosd error, you can rm -r your old eosio-wallet folder from previous install if needed)

9. Before importing any keys, view cleos wallet keys and cleos wallet private_keys commands to verify the wallet has no keys.

10. import your same private key with: cleos wallet import use same: Kx9c3uvybEkFuMkckocfW7kzKsju3vquSpT51UamXatJSMiqNmhX

11. view EOS key pair: cleos wallet private_keys

12. notice that the public key generated by cleos does not match the public key generated by "Offline EOS Keys Generator", and the private key is also different now. cleos wallet private_keys

example cleos keys after cleos wallet import command, using same keys from "Offline EOS Keys Generator" above: cleos pair: password: [[ "EOS6spLEsAHJBL4MahEWY4pwgXpUdpX1ov4DKvsxsNEKrgfWDvVsf", "5J2VnX7nuATZq7WpXKGL9QjbHWd11fUr3E1vUJ8CSxi5QWdiYG7" ] ]

nothing matches at all.

This is with eos 1.1. for older versions of EOS, importing a bitcoin private key would work and give the same private key, but a different public key. I'm not going to install an older version to repro that though.`

Question: do you know why my Kx9c3uvybEkFuMkckocfW7kzKsju3vquSpT51UamXatJSMiqNmhX private key changed to 5J2VnX7nuATZq7WpXKGL9QjbHWd11fUr3E1vUJ8CSxi5QWdiYG7 in eosio software? perhaps if I can convert private keys back and forth, I can find the private key that matches my 170 eos accounts I lost during the conversion. older versions of eosio didn't convert these private keys, so I'll try importing my real old private keys that didn't convert into the new v1.1 and see what happens.

[RayMetz100]

bitaddress.org has a tool to swap and view BTC compressed and uncompressed private keys.

https://github.com/pointbiz/bitaddress.org

Once you get into the tool, you can click Wallet Details and it will give you a blank field to enter your private key. using the keys from the previous note, I entered Kx9c3uvybEkFuMkckocfW7kzKsju3vquSpT51UamXatJSMiqNmhX

The tool returned 5J2VnX7nuATZq7WpXKGL9QjbHWd11fUr3E1vUJ8CSxi5QWdiYG7 the same as cleos imports.

but when I use the eoscafe Offline Key generator tool, "Find Public Key" feature, and try those same two private keys, I get two different public keys.

uncompressed WIF 51 characters base58, starts with a '5' 5J2VnX7nuATZq7WpXKGL9QjbHWd11fUr3E1vUJ8CSxi5QWdiYG7 EOS6spLEsAHJBL4MahEWY4pwgXpUdpX1ov4DKvsxsNEKrgfWDvVsf

WIF Compressed 52 characters base58, starts with a 'K' or 'L' Kx9c3uvybEkFuMkckocfW7kzKsju3vquSpT51UamXatJSMiqNmhX EOS7hweQQgQrRXJ2jewoxohp4z3JF9HWa3wJyrFY9ksvZB7M83BSv

The two private keys above should be the same. Why do the key checker tools give different public keys for these when cleos does not?

cleos gives same same public key example cleos wallet import Kx9c3uvybEkFuMkckocfW7kzKsju3vquSpT51UamXatJSMiqNmhX 5J2VnX7nuATZq7WpXKGL9QjbHWd11fUr3E1vUJ8CSxi5QWdiYG7

the second one gives "Key already exists". I cleared cleos with wallet remove_key command and imported them in reverse order as well. both import to same public key EOS6spLEsAHJBL4MahEWY4pwgXpUdpX1ov4DKvsxsNEKrgfWDvVsf

when I put the same two keys into the EOS key checker tools: I get different public keys

[RayMetz100]

If I can get more details on the bug in the wallet checker tools why Kx9c3uvybEkFuMkckocfW7kzKsju3vquSpT51UamXatJSMiqNmhX gives the wrong public key EOS7hweQQgQrRXJ2jewoxohp4z3JF9HWa3wJyrFY9ksvZB7M83BSv then perhaps I can find a matching private key for EOS7hweQQgQrRXJ2jewoxohp4z3JF9HWa3wJyrFY9ksvZB7M83BSv which is similar to where I registered my 170 EOS to. Doubtful, but worth a look.

The first priority is getting the key checkers updated to behave like cleos and not give more incorrect public keys that have no matching private key in cleos. The public keys match fine in the key checkers, but that doesn't match with eos software.

[firmwareguru]

@RayMetz100 I've found the bug. It has already been identified and patched in this issue: eosio/eosjs-ecc#16. The WIF keys with a leading K or L correspond to so-called compressed public keys; all this means for the private key is that an extra 0x1 byte is appended. The javascript libraries were letting this byte pass on through with the rest of the private key material to the public key generator functions.

The ecc javascript library used by this tool is pulled from a node.js repostory that has not been updated. The web browser offline key checkers use the same library just copied into a local file called ecc.js. So they all suffer from the bug that generates a different public key than cleos for WIF private keys beginning with K or L.

[RayMetz100]

if I have my KL compressed private key, can I get a different leading 5 private key that matches the public key that the KL private key generated? Is the extra 0x1 byte before the hash and reversable by converting my private key to a new matching one? If the extra 0x1 happened after the hash, then I don't think there would be any way to generate a matching private key.

[firmwareguru]

With your KL key you'll get one of two public keys based on which tool you use (EOSKey or cleos). Given a public key, you cannot reverse engineer a private key no matter what you do. You can only generate public keys from private keys and check for a match of the public keys. The extra 0x1 byte happens early in the WIF key generation process, before any checksums and hashes and base58 encodings are performed. eos.io software uses a standard key format called K1 that corresponds to the non-compressed WIF format, so eos keys start with 5. I'm really not sure how to recover lost EOS tokens.

[RayMetz100]

"The extra 0x1 byte happens early in the WIF key generation process, before any checksums and hashes and base58 encodings are performed." Is there a way to input a KL key, and have it reverse the extra 0x1 byte, and somehow output the modified KL key without the extra 0x1 byte? Before the hash.

If I had a new patched KL key, then I could import it to cleos and cleos would generate the same public key that the bugged EOSkey generated with my previous KL key.

Can you send me the github path to the EOSKey source that contains the 0x1 byte bug? Maybe I can step through the corruption of my KL key and uncorrupt it somehow to a different working KL key.

[jcalfee]

@RayMetz100 is correct, this is a bug in eosjs-ecc .. This affects users that are able input a bitcoin formatted compressed private key (wif that starts with K or L).

This comment is one example of how to verify the issue, upgrade, and re-test for the fix. https://github.com/EOSIO/eosjs-ecc/issues/16#issuecomment-408941034

Let me know if you have any questions.