Skip to content
This repository has been archived by the owner on Nov 21, 2019. It is now read-only.

Error View Wallet Info "Invalid password. :RangeError: private key length is invalid" #259

Closed
j13n opened this issue Oct 27, 2016 · 25 comments

Comments

@j13n
Copy link

j13n commented Oct 27, 2016

Hi,

I'm trying to view the wallet to download the corresponding keys. After entering my password I get the "Viewing wallet" screen, although nothing is filled in. However, in the console I see a "Invalid password. :RangeError: private key length is invalid" error. I'm positive that I am using the right password. The behaviour is different when I enter a invalid password which just returns me an "Unable to decrypt" message.

Anyone that has seen this before? Any help would be greatly appreciated.

error

@tayvano
Copy link
Contributor

tayvano commented Oct 27, 2016

edit:

Post-issue summary here: #259 (comment). You're not going to want to read this whole thread and it's mostly trying to figure out what was happening, not how to solve it.


I just went through all the emails and the only time we've received a message regarding this that eventually got resolved was with a guy using an private key from Icebox.

Is this the same in your case?


Regardless, go to the console and paste the following:

chrome.storage.sync.get(null, function (data) { console.info(data) });

It will spit out all your wallets and each will look like this:

0x59738BD1D415EB654Ade0370B57B15E129b4eD25:

"{"nick":"asdfasdf","priv":"{\"version\":3,\"id\":\"d65c3ae1-76ef-4952-b520-e15b1d0833c2\",\"address\":\"59738bd1d415eb654ade0370b57b15e129b4ed25\",\"Crypto\":{\"ciphertext\":\"aa9223446d64461e1061780c0ce034de4c46909443167157a10259d8cbd9eb52\",\"cipherparams\":{\"iv\":\"edf570963c94b60a949fdda988fcb9fa\"},\"cipher\":\"aes-128-ctr\",\"kdf\":\"scrypt\",\"kdfparams\":{\"dklen\":32,\"salt\":\"6ac19f5ba2b6448a61cd02eeda0ac9108c6380c4962b96d274a5994077196bde\",\"n\":1024,\"r\":8,\"p\":1},\"mac\":\"e5c0dd174c96c844a1768bfa1d116fecbd7dc917b3d150abfe8e30fb15c2e8b9\"}}","type":"wallet"}"

Copy that to a .txt document.

(hold on testing)

@tayvano
Copy link
Contributor

tayvano commented Oct 27, 2016

Ugh. Okay. This is going to get messy. Bear with me.

In a NEW text document paste the following:

{"address":"ADDRESS_HERE","Crypto":{"cipher":"aes-128-ctr","ciphertext":"CIPHERTEXT_HERE","cipherparams":{"iv":"IV_HERE"},"kdf":"scrypt","kdfparams":{"dklen":32,"n":N_HERE,"p":1,"r":8,"salt":"SALT_HERE"},"mac":"MAC_HERE"},"id":"ID_HERE","version":3}

Copy the Address, Ciphertext, IV, N, SALT, mac, and ID from your first text document and paste it into the areas I've designated in your second document.

Save it as UTC-YOUR_ADDRESS_HERE_WITHOUT_0X_BEFORE_IT as either a .txt, .json, or no extension.

Go to https://www.myetherwallet.com/#view-wallet-info and attempt to decrypt it.

If you get an error, let me know.

I'm sure there is an easier way but that's all I got for now.

@j13n
Copy link
Author

j13n commented Oct 27, 2016

Hi @tayvano, ok so I have a different output when pasting the first command you mentioned. The JSON that returned only had the "nick", "priv" and "type" keys like this:

Object {0x093<removed>: "{"nick":"Wallet","priv":"<removed>","type":"wallet"}"}0x093<removed>: "{"nick":"Wallet","priv":"<removed>","type":"wallet"}"

I'm guessing that is causing the error... Seen this before?

Many thanks for the help so far!

@tayvano
Copy link
Contributor

tayvano commented Oct 27, 2016

Oh that's interesting. Hmmmm...

We did a lot of testing before migrating to the new keys (months and months ago) so that this wouldn't be an issue but apparently something went wrong somewhere.

Try copying just the information after "priv": and pasting it into https://www.myetherwallet.com/#view-wallet-info -> Private Key

It should ask for your password.

If it decrypts that way successfully, remove the wallet from your Chrome Extension and then re-add it using the same method (add wallet -> private key)

If it doesn't decrupt successfully, let me know.

You may have issues re-adding it to the CX if the password is under 3 characters or something. If that is the case, let me know and I'll update the validation so that you can add it, even with your super short password.

@j13n
Copy link
Author

j13n commented Oct 30, 2016

Ok. So when I went to the myetherwallet.com wallet it decrypted succesfully (although nothing happened afterwards, just the message in green). However in the console I noticed the following:

RangeError: private key length is invalid

selection_002

Thanks for the help so far! It is really appreciated.

@vied12
Copy link

vied12 commented Nov 2, 2016

I have exactly the same problem when I try open my keystore file on https://www.myetherwallet.com
Please let us know if you have found a solution or if you need additional information

@tayvano
Copy link
Contributor

tayvano commented Nov 2, 2016

I just went through all my old backups and still can't recreate this issue. 😠

Can you give me details like:

Where did the file come from? When / where was the wallet generated? How many characters is the private key? Or, if it's a JSON, what are some of the keys that are in it (januszdotnl already did this above)

I'm going to try to revert back to an old version of the chrome extension, generate a new wallet, and see what happens.

I'm also trying to nail down when this started occurring and maybe the commits before that will shed some light?

@tayvano
Copy link
Contributor

tayvano commented Nov 2, 2016

Here's another report when user was trying to use ledger on offline. Wondering if it can also help narrow down where this error is coming from.

https://www.reddit.com/r/ethtrader/comments/58o12k/has_myetherwallet_backend_been_down_during_the/d92cwa6/

@tayvano
Copy link
Contributor

tayvano commented Nov 2, 2016

So I just tested with all private key versions found in

CX v 0.0.3
CX v 0.2.2
CX v 3.1.3

And had no issues. I also created a key in 0.0.3 and then updated the app to 0.2.2 and then 3.1.3 and still had no issues decrypting or viewing the wallet.

Now I'm really confused.

@tayvano
Copy link
Contributor

tayvano commented Nov 3, 2016

@vied12 @januszdotnl

Do either of you have a version of the key that is NOT working that does NOT have your life savings in it that you would be willing to email us?

We've been looking through stuff all night and cannot figure out what is going on.

We would attempt to convert to a working key first and immediately transfer all the funds in it to a new address that you designate. Then we would use that key to figure out how to keep this error from happening to others.

Thank you in advance.

@vied12
Copy link

vied12 commented Nov 3, 2016

Hi @tayvano ,
It has been generated by Ethereum-Wallet-linux64-0-7-2 the last 27th May.
It's not a version issue, because the day before, the 26th May, I created another wallet in the same conditions that I am able to open on https://www.myetherwallet.com/#view-wallet-info

json file name: UTC--2016-05-27T06-58-44.141984544Z--4692c5add9815e24b1b23ccc016280b3d54ff359
{"address":"4692c5add9815e24b1b23ccc016280b3d54ff359","Crypto":{"cipher":"aes-128-ctr","ciphertext":"...","cipherparams":{"iv":"5a493f54a0bd8d7453297b84d17f7c51"},"kdf":"scrypt","kdfparams":{"dklen":32,"n":262144,"p":1,"r":8,"salt":"..."},"mac":"..."},"id":"348bbecd-0c21-4996-baaf-2df3c30dc328","version":3}

Sorry I don't have empty wallet that doesn't work

@tayvano
Copy link
Contributor

tayvano commented Nov 3, 2016

@vied12 Thank you.

So I replaced the address, ciphertext, iv, salt, mac, and id with the values found in one of my keystore files created around the same time via ethereum wallet mac and it decrypted. the cipher, kdf, n, and so on already matched. So it's not a file format thing.

Let's try this: can you save the following in a file named like test and see if you can unlock it via https://www.myetherwallet.com/#view-wallet-info?

{"address":"e1ef40082892696d327c6029f5d7b142464ac76b","crypto":{"cipher":"aes-128-ctr","ciphertext":"e57d2c34f7e1a0f70f529f43b7220d1a69b949b36923cd2445cb3c833c140571","cipherparams":{"iv":"710b0da4f3017bcf171d6747c421ba04"},"kdf":"scrypt","kdfparams":{"dklen":32,"n":262144,"p":1,"r":8,"salt":"20425865eca94ff90cf2782892fda124ab4c07b6931181c80e323365258040ae"},"mac":"b7835b31cf1216660d1f88ff6c2f67273a7dbe3dc446ca75480f760f3b19864d"},"id":"69bbef8b-977d-4e27-8346-a8c669656ff2","version":3}

password is 1234567890

@vied12
Copy link

vied12 commented Nov 3, 2016

Thanks for keeping trying :)

I can unlock it

Le jeu. 3 nov. 2016 à 11:08, Taylor Van Orden notifications@github.com a
écrit :

@vied12 https://github.com/vied12 Thank you.

So I replaced the address, ciphertext, iv, salt, mac, and id with the
values found in one of my keystore files created around the same time via
ethereum wallet mac and it decrypted. the cipher, kdf, n, and so on already
matched. So it's not a file format thing.

Let's try this: can you save the following in a file named like test and
see if you can unlock it via
https://www.myetherwallet.com/#view-wallet-info?

{"address":"e1ef40082892696d327c6029f5d7b142464ac76b","crypto":{"cipher":"aes-128-ctr","ciphertext":"e57d2c34f7e1a0f70f529f43b7220d1a69b949b36923cd2445cb3c833c140571","cipherparams":{"iv":"710b0da4f3017bcf171d6747c421ba04"},"kdf":"scrypt","kdfparams":{"dklen":32,"n":262144,"p":1,"r":8,"salt":"20425865eca94ff90cf2782892fda124ab4c07b6931181c80e323365258040ae"},"mac":"b7835b31cf1216660d1f88ff6c2f67273a7dbe3dc446ca75480f760f3b19864d"},"id":"69bbef8b-977d-4e27-8346-a8c669656ff2","version":3}

password is 1234567890


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#259 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AALBiS8qfC3a61yZe3uQqgcdHkoJPF5cks5q6bKEgaJpZM4KiD4-
.

@vied12
Copy link

vied12 commented Nov 3, 2016

Maybe this can help. My private key in the buffer is only 31 length, when it should be 32.

selection_097

@tayvano
Copy link
Contributor

tayvano commented Nov 3, 2016

@vied12 That's actually quite helpful.

So what I'm guessing is that something we are using implemented better checks for private key length and that's why this is happening? I thought it might have been ethereumjs-utils but apparently rolling that back breaks the entire site.

So instead, I'm going to have YOU roll back and see if you can decrypt there and then at least you can (hopefully) decrypt and access your funds and whatnot.

To do this, download the version of our repo from a couple months back here: https://github.com/kvhnuke/etherwallet/archive/dfda56db1a3408a52e29afbcaedd64363b4fe9ea.zip

unzip it and double-click index.html in that folder and you should be ready to go.

If you can decrypt it, you can most likely send from it, or use the view wallet info tab to grab your unencrypted private key and use that on the current version of the site for the time being.

If that fixes it then we have narrowed the problem and may be actually able to fix it. It's 4am though and I just broke the site once so we're going to bed.

I feel like we're closer to solving the problem. But we're still unable to recreate the issue which is the oddest thing. But hopefully this gives you access to your funds again, which is the most important thing.

Thanks for all your help.


note to future-awake-self: eth-lightwallet seemed to have a similar issue....but it was a long time ago. I don't know how these are related but I feel like they might be? Consensys/eth-lightwallet#60

@vied12
Copy link

vied12 commented Nov 3, 2016

Haha yes go find some rest that you deserve !

Unfortunately I have the same error with https://github.com/kvhnuke/etherwallet/archive/dfda56db1a3408a52e29afbcaedd64363b4fe9ea.zip

Good night and sweet dreams

@tayvano
Copy link
Contributor

tayvano commented Nov 3, 2016

Poop. I had high hopes for that. We can try going back further in time?

Im starting to wonder if this is an ethereum wallet issue.

@januszdotnl what is the N value in your private key that isn't working? 262144?

@tayvano
Copy link
Contributor

tayvano commented Nov 3, 2016

Found it. Look like everyone's ensuring 32 bytes now. I'm sure we updated a library that now checks for 32 bytes when it didn't before. And since there's such a low probability of having a key with 31 bytes, we couldn't recreate. @kvhnuke can fix by adding padding tomorrow. Good details in this issue:

https://github.com/ethcore/parity/issues/2263

@vied12
Copy link

vied12 commented Nov 3, 2016

Cool! Thanks a lot for all your investigations ! I'm waiting for any update
then

Le jeu. 3 nov. 2016 à 13:00, Taylor Van Orden notifications@github.com a
écrit :

Found it. Look like everyone's ensuring 32 bytes now. I'm sure we updated
a library that now checks for 32 bytes when it didn't before. And since
there's such a low probability of having a key with 31 bytes, we couldn't
recreate. @kvhnuke https://github.com/kvhnuke can fix tomorrow.

ethcore/parity#2263 https://github.com/ethcore/parity/issues/2263


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#259 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AALBifW7ATDG9yjnZY8Nzyz90cXuGqgaks5q6czOgaJpZM4KiD4-
.

@tayvano
Copy link
Contributor

tayvano commented Nov 3, 2016

@tayvano
Copy link
Contributor

tayvano commented Nov 3, 2016

Alright just pushed an update (#dc995ff) which hopefully fixes it. Not live on the Chrome Extension yet, so please try on MyEtherWallet.com

@tayvano
Copy link
Contributor

tayvano commented Nov 4, 2016

Resolved in f1b6a13 by padding keys with 30 or 31 bytes so they are the required 32 bytes. No longer occuring in >v0.3.2.1

@tayvano tayvano closed this as completed Nov 4, 2016
@vied12
Copy link

vied12 commented Nov 4, 2016

It works now perfectly ! Thanks again

@tayvano
Copy link
Contributor

tayvano commented Nov 4, 2016

@vied12 Yay! So glad we finally got this worked out. What a weird situation.

Go buy a lotto ticket. You were one of the lucky 0.3% to have a key with 31 bytes. 🎰

@tayvano
Copy link
Contributor

tayvano commented Nov 5, 2016

Since this thread is long but certainly going to be something that other developers encounter, here is a summation.

  1. Geth (and possibly others) sometimes generate valid private keys that are <32 bytes. Read about the details of how / why / how often this happens and why its valid: Geth keys with ciphertext of 31 bytes (62 hex digits) length openethereum/parity-ethereum#2263 (comment)
  2. Some libraries check for == 32 bytes rather than the more complicated validation which will prevent the rare people who have keys with byte lengths under 32 to not be able to decrypt due to this validation, or not allowing them to interact with that key even if it is decrypted (this is what happened in our case - would decrypt fine but other functions like getBalance() would fail)
  3. The solution is:

Arguably Web3 Secret Storage Definition should define padding if the private key to-be-encrypted can be represented as less than 32 bytes. Since Ethereum uses big-endian would suggest we define higher-order (left) side zero byte padding to always get 32 bytes for encryption.

So moving forward, most should already pad keys with less than 32 bytes. However, if you encounter an old key you should pad it before attempting to interact with it.

  1. Keys with less than 32 bytes to test with can be found here: https://github.com/Gustav-Simonsson/go-ethereum/blob/7cc6b801e0967e5ebfa26b9f670675acea6e3a20/accounts/testdata/v3_test_vector.json (super helpful!)

hackmod pushed a commit to hackmod/etherwallet that referenced this issue Sep 26, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

3 participants