Linux unable to decrypt Windows genned keystore file

[satori-q3a]

So...

I installed Geth 1.8.6 and Mist 1.9 on a Windows 10 (1793) machine and created a keystore file, and verified that it was accessable / decrypted thru the 'geth account update' command using the password created for it.

I've since updated to Geth 1.8.10 and Mist 1.10 on Windows 10 (1803) and verified that the keystore file are still being decrypted correctly.

I installed Geth 1.8.10 and Mist 1.10 onto a debian 9.3 machine to allow me some redundancy in being able to access the wallets.

I then copied the Windows keystore file to a usb drive and used that to copy the file onto the Linux system. I found that altho the linux geth can list the key, it cannot decrypt using the password that was used on the windows machine.

I then genned a new keystore file on the Linux system and copied it on to the Windows system, and found that windows can access and decrypt both the windows and linux genned keystore files correctly.

Is there a problem with passing a window's genned keystore file to linux? Where as passing a linux genned keystore file to Windows, works fine.

[philsmd]

Did you generate the account with geth ? ... or did you use the GUI (mist) to generate the keystore file?
in other words, did you use geth.exe on the command line (cmd) or launch the graphical interface (mist).

This could be related to #16286 , but to verify that we need more details.
Unfortunately, it would also be somehow helpful to know if there are some special characters within the passwords, but I do not recommend revealing even parts of your sensitive password.

It could help to reproduce the problem again with the same setups (windows vs linux with a easy, non-sensitive password).

This other github issue of mist (ethereum/mist#3513) could also be related here. @holiman, a ethereum dev, even offered to get in touch with affected users in a secure manner (encrypted email conversation to try to troubleshoot password problems) : ethereum/mist#3513 (comment) ... you could try to get in touch with him if you do not want to share the (empty!) keystore file and password here (again: do not do it if the password is sensitive etc, create other test accounts instead!).

Anyway, you should not leave any funds on the keystore file before sending the keystore file to someone (and do not get used to send any keystore files in general! it's very dangerous. only send them if you accept that the recipient will get in touch with the sensitive data, such as ether address, related addresses, passwords, funds etc) trustworthy for analysis (you said that you can unlock it with linux, therefore if there are some ether in it, you should move them beforehand).

It would be interesting to get some of these test keystore files that work with windows, but fail with linux... for debugging the problems mentioned within above issues (maybe they are related, maybe not at all).

[holiman]

If you can generate, or have already, an (empty) wallet file which can be decrypted in one OS but not the other, that would be very very interesting for us to look into.

[satori-q3a]

On the windows instance, I let Mist auto gen the keystore file and verified the password thru geth's CLI account interface.

On the LInux instance, I used geth's CLI to gen the keystore file and verified the password. In both instances, the keystore directories were initially empty.

Both keystore files use a password with a special character "_". While Windows' geth is able to decrypt both windows and linux versions, Linux geth is unable to decrypt windows' version.

---

update:

Hmmm.... I decided to use windows' geth to update it's keystore file and gave it the same password as the old, and now Linux is able to decrypt the updated windows' keystore file.

Looks like Windows Mist is making a keystore password that works only on Windows, where as windows geth genned password is applicable to both windows and linux.

[philsmd]

that's interesting.
It seems unrelated to the "liner"-problem (mentioned here: #16286).
I do not think that "_" should be considered as a special character, but we will see (normally only non-ASCII characters, like umlauts or special unicode characters etc should be considered special and could lead to some encoding problems or similar).

Are you able to generate a very fresh/new account with exactly the versions you used beforehand and still come up with the same problem? Is the problem easily reproducible on your systems ? Can you try to reproduce it also with different passwords ?

Are you sure the keystore file is not already much, much older? What's the date in the file name (UTC--...), is it just a few weeks/months back or much older?

You didn't really answer the question about sharing the (original) keystore file, do you think that is possible/acceptable ? As said, you can problably also contact @holiman privately and make sure that the account with that specific address has no funds left (was emptied). It's important that the file is the original file, not the "updated" one (that works anyways on all systems).

Did you try to run the "update" also on the linux machine (with the original keystore file) ? Did that always fail?

[satori-q3a]

I'm unable to reproduce the problem. I genned a new account under Mist and passed that to Linux, which accessed it correctly. Current config is:

Mist 1.10 (beta) / geth 1.8.11 / Windows 10 (1803)

The 'strange' account file is dated Feb 2, 2018, which suggest a config of (if I recall correctly):

Mist 9.2 / geth 1.8.6 / Windows 10 (1793)

I only know that the 'fix' is to reapply the password to the windows account, using windows geth 1.8.10, which makes the updated file amiable to Linux.

[philsmd]

I'm interested what the devs think about your finding that the "update" on windows fixed the problem. Maybe they know how exactly the update could have "fixed" the keystore file (as far as I understood the update mechanism only worked on windows, right?).

In general I would say that a problem in most cases is (or at least should be) somehow reproducibe (with same setup and inputs etc). If it's not reproducible there might be further details that are missing etc and it needs to be tested/redone in a different manner.

Are you sure that the keystore file is of the new format and contains these:

"cipher":"aes-128-ctr"
"kdf":"scrypt"

I'm not sure what else changed between the different keystore formats, maybe @holiman etc has an idea what exactly the update could have fixed (besides converting between the old and newer formats, if as you said the format/version should be the newest one).

I think that without having the keystore file and without being able to reproduce the problem (neither the devs, nor me, nor you) we can't really do much here.
You could in theory debug the "update" mechanism and see where exactly the linux version fails and where and why the windows version continues with the "update" without error message, but this of course needs some debugging skill and testing on both platforms etc (and most importantly we would need the original - not modified - keystore file which didn't work on linux).

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.