"Provided AES key is wrong" when decrypting wallet

[clubshaft]

I have a serious bug ! import wallet work . I see all my transfers and my saldo ''coins''

when I wanna sent some coins it ask me for password . like it always do now monts from may .

I know my password 100% here is no doubt about it .

I get the error message ► provided AES key is wrong . this is insain ! ! ! why you let me enter a password to my wallet ? not safe without a password you tell to the people . BULLSHIT + 20 BTC my own coins from 2 years pfffffff I can do nothing with it becouse off that stupid password BUG ( scam?? )

Iam now 7 days trying to fix this but nothing work . coincidentally the backup wallet and backup key also give an error . all the other files are ok from my old wallets . they are all there but there is no money on it .

the error message was "NUL" wit the backup key and backup wallet file .

I'm totally misled by multibit WTF I I knew this was going to give problems . no recovery for passwords LOL so that is safe ????? never I read anny messages for warning me becouse the danger off using a password . I know my password let that be clear . more than 23 coins WTF .

████ people if you read this do your password gone before it is to late ! ! just rar the file with password two times or 3 times . up some rar with password in gmail there it stays till we dead . for me it is to late feel verry bad what a massive scam damn ███

[gary-rowe]

@clubshaft Thanks for coming back to the issue and sharing your additional findings - much appreciated.

I've edited the title to make it more search engine friendly in case others need to reference this information.

To summarise your approach:

1. Get "Provided AES key is wrong" error for what is believed to be correct password
2. Revert to earlier .key files through recovery software (MultiBit makes multiple copies for exactly this reason)
3. Enter password again and private keys are restored

That sounds like there was a fault with the original .key file that manifested as unrecoverable data (encryption + partial/broken data = mess). Your recovery software struggled to successfully lift the data off the hard drive but eventually was able to reconstruct the file correctly.

If it had been output incorrectly by MultiBit such a recovery would not have been possible.

Therefore it seems much more likely that a disk problem has occurred after MultiBit has written the data which has corrupted the file. Here is a great explanation of the technical details of how this can occur, and what recovery software can do to repair them.

Overall, encrypted data written to a single disk is fragile and needs to be regularly backed up to multiple locations to ensure its ongoing safety. We are addressing this problem through MultiBit HD (the successor to MultiBit Classic) and the use of seed phrases in conjunction with encrypted cloud backups and hardware wallets. The combination of these three approaches provide maximum protection for your bitcoins.

[tonyclifton13]

Forgive me for not understanding what all of that means, but are you saying that this is possibly a problem other than a typo when setting the password? I really don't want to send this off to a recovery service if the problem isn't with my password.

[tonyclifton13]

Maybe the question I should be asking is, IF I am experiencing a similar problem, then sending this off to a recovery service would not do any good because it is a disk problem?

[clubshaft]

it whas no disk problem !

after cleaning my computer from spyware my 2 wallet deleded. and there where no files off the second wallet . only from the first wallet but that one I dont use annymore . it is totaly not safe to sent your disk . and it is not needed the police also use the program recuva to recover deleded files in an investigation.

[clubshaft]

therefore it is good if you would run an new instalation first wipe the harddisk off do an low format . if something happen you can easy recover the files becouse you started from a clean disk

[gurnec]

(edits as of 2015/Jan/10 in bold)

Although the "Provided AES key is wrong" message looks suspicious it is merely a coincidence. Here's the code that does the decryption work from the Bitcoinj library ECKey.java:

@gary-rowe I've been following this issue on a thread over at bitcointalk and was just made aware of this GH issue. I must respectfully disagree with your statement above. I don't mean to be argumentative -- I'm only offering a different perspective in the hopes that it can help lead to a resolution.

Here's my line of reasoning. If any of these steps is incorrect, than so is the conclusion....

1. A private key is stored as a BigInteger.
2. Before being encrypted, it is converted to a big-endian byte array and zero-padded to exactly 32 bytes.
3. It is then prepared for AES-256 encryption in CBC mode. CBC mode requires a plaintext whose length is a multiple of blocksize-of-underlying-cipher (16 bytes for AES-256). Between 1 and blocksize (16) PKCS7 padding bytes are appended (in PaddedBufferedBlockCipher::doFinal()) -- for a 32-byte plaintext, 16 bytes are appended (each having a numeric value of 16).
4. The resulting 48-byte array is encrypted and saved.
5. Decryption works in reverse: first the 48-byte array is decrypted.
6. The trailing 16 bytes of padding are verified by PaddedBufferedBlockCipher::doFinal(). If any of these trailing bytes != 16 are invalid, InvalidCipherTextException is thrown, which eventually is translated to KeyCrypterException("Could not decrypt bytes") in KeyCrypterScrypt::decrypt().
7. If all 16 padding bytes are correct, eventually ECKey::decrypt() checks a derived public key against the stored public key and throws KeyCrypterException("Provided AES key is wrong") if they do not match.

(6) and (7) above lead to two different error messages. The point that I'm trying to make is that if the exception in (7) is thrown, that means that all 16 decrypted padding bytes were correct, and it seems astronomically unlikely that this can occur unless the decryption key is correct (somewhere around 1 in 2^128?) unlikely but entirely feasible that this can occur.

Because the exception in (7) is being thrown, it seems very likely the password is correct. So what's left? Was the private key corrupted before being written to disk? (If it were corrupted after being written to disk, (6) would be thrown instead.) Is the stored public key corrupted (but if it were, wouldn't its displayed balance be wrong)? How can I explain that the .key files can't be decrypted with this supposedly good password (I can't)?

I'm pretty confused by the conclusion above.... if you have time, could you offer any insight?

[gary-rowe]

Thank you for taking the time to look more deeply into this @gurnec - much appreciated. I agree with your reasoning, and the odds of (7) it actually occurring with an incorrect password are much lower than I first thought. I've amended the original comment to reflect this.

Here's what we know:

1. @clubshaft was able to use recuva to access alternative .key files that contained a correct copy of the private key
2. @tonyclifton13 is still stuck with a corrupted file that is not decrypting correctly

It is possible that in some cases the private key is written out incorrectly, however the export process that creates the .key file also reads the result back in to verify that the data can be successfully decrypted.

It is possible that during this process the JVM merely reflects the write buffer rather than the actual physical contents of the file on disk but that is a poor implementation of a JVM if that were the case and would be too unreliable to reach production.

The possibility that I suggested in my later comment is that the file suffered corruption after writing, possibly due to fragmentation, which resulted in a file that could be correctly stitched back together by dedicated recovery software. This would fit the observations: encrypted key exported by MB, verified as decryptable, time passes, decryption fails, recovery software rebuilds file, decryption passes.

[gurnec]

@gary-rowe That seems reasonable to me (and the OS filesystem cache could be equally blamed as the JVM).

I believe that @tonyclifton13 has tried both a wallet file and a .key import, and ran into trouble with both. That would imply they both are corrupted; although this also seems unlikely, the other possibilities seem even more unlikely. Hopefully he will give the openssl option a try.

[gary-rowe]

Thanks. Would you mind providing a link to the BitcoinTalk discussion in case further information pops up there?

One of the problems with crypto is that it is so hard for non-techies to work with. We have an error reporting tool in mind for MultiBit HD to assist with this kind of problem in the future but it isn't scheduled until Public Beta 1.

[gurnec]

@gary-rowe The BitcoinTalk thread is here: https://bitcointalk.org/index.php?topic=813278.0

Thanks for taking the time to look into this.

[tonyclifton13]

I also sincerely appreciate everyone looking into this and taking my situation seriously. It sounds like there is a better understanding of what has gone wrong. As I said in the other discussion, I think my best bet now would be to find a friend that may be able to help me get this wallet unlocked. I will update this thread with any progress made. I will also post any further questions here if you guys don't mind checking in occasionally. Thanks again!!!

[gary-rowe]

We're happy to help where we can. The problem with this kind of issue is that it is next to impossible to replicate and therefore debugging is theoretical and time consuming. The more information you can give us the better (operating system, version of Java, any previous disk problems, other applications having troubles etc) so that we can eliminate lines of enquiry.

We have a couple of issues against MultiBit HD (see #224 and #225) that will introduce high frequency stress tests against the equivalent of this code so it will receive attention. That said, we will be strongly encouraging anyone using MultiBit Classic to migrate to MultiBit HD in the near future.

[tonyclifton13]

To give you a little more insight, I am using OS X 10.9.5. but I'm not sure what version of Java I have. As far as I know I haven't had any other disk problems. I've been thinking about the moment I installed Multibit and trying to remember any specific details. I'm fairly certain I would have had a VPN running at the time, as I often do. I also believe that there is a good possibility that the coin was still in the process of confirming the transfer at the moment that I set a password to the wallet. Im certain Safari was open as well. Other than that I can't really think of any other details. Unfortunately I haven't been able to find much help with unlocking this wallet. I plan on having a little more time this weekend to dedicate to it and do a little more research on Openssl for Mac. I will continue to post any progress made to this thread. If anyone comes up with more ideas that may be helpful, please post them.

[gary-rowe]

Thanks for the update and please do keep updating this thread with any new insights.

If you can spare the time, learning OpenSSL and other command line tools such as GPG is worth the effort. Start small and work up from there.

[tonyclifton13]

Unfortunately I still haven't been able to access my account or retrieve my coin. I've had a few friends come over and take a look, but it seems to have everyone stumped. I've come back here to ask if there is any other options I have. Obviously I've been without that coin for some time now, but I would still like to get it back. My savings has take a hit as a result of not having this coin, and I'm at a time now where that savings is needed. Any advice would be greatly appreciated.

[gary-rowe]

Sorry to hear that you've not been able to recover the file. Were you able to get any OpenSSL output? I can't emphasise enough how important that process is for picking this problem apart. Alternatively, perhaps contacting one of the many Bitcoin recovery services would help? I can't endorse any in particular, but I'm sure Reddit can offer some advice (just trawl the /r/bitcoin archives).

[gurnec]

@tonyclifton13, FYI I added a post over in the thread at BitcoinTalk.org (since it's a little bit off-topic here in the MultiBit repo...)

[gurnec]

I should point out that I'm pretty sure my comment above has a significant mistake in it. In particular:

6. The trailing 16 bytes of padding are verified by PaddedBufferedBlockCipher::doFinal(). If any of these trailing bytes != 16, InvalidCipherTextException is thrown, which eventually is translated to KeyCrypterException("Could not decrypt bytes") in KeyCrypterScrypt::decrypt().

I believe this is wrong-- there's no requirement that the decrypted padding must be of length 16, only that it must be valid. A single trailing 0x01 byte constitutes valid padding of length 1. Therefore:

it seems astronomically unlikely that this can occur unless the decryption key is correct (somewhere around 1 in 2^128?)

This chance would be a bit higher than 1 in 256, so as @gary-rowe initially said, I think it's entirely feasible that an incorrect password can result in the "Provided AES key is wrong" message (less likely, but not "astronomically" so).

Sorry for the oversight....

[ghost]

Thanks for the update - 1 in 2^128 was a worryingly rare event to see in real life whereas 1 in, say, 1000 is likely to happen with MultiBit's installed user base.

In the next version of MultiBit we have put in password recovery from the seed phrase so (assuming people write down the seed phrase as we ask them to) we should hopefully eliminate forgotten passwords.

[clubshaft]

the password whas not forgotten ! it simply not work . now I'am using two backups the first one is not with a key and this file I winrar with pass . and second backup is multibit with pass wich cost me all the problems in this tropic . the winrar file with pass is absolutly the safest way to store your backup off multibit

[ghost]

Encrypting the whole wallet with winrar is a good solution yes. We are doing something similar (using AES to encrypt the whole wallet) in MultiBit HD.

[clubshaft]

I forgot to say that after making backup without pass. you must delete the recovery file manually on your pc with http://www.fileshredder.org in case someone steal your PC and run a recovery program like Recuva. they still can acces your coins . so this is verry important to do .

[vamosrafa]

I'm having the same problem. So @clubshaft did you just take an older .key backup and import it into a new installation. I will look into your solution, since I am fairly certain my Multibit key was corrupted, my password gives the "provided AES key is wrong" message. I had given up thinking I must have typed a different password, as opposed to my usual secure one. @tonyclifton13 have you had any luck with recuva?

[Avuidrauxs]

I also have the exact same issue my password is not working at all , it keeps telling me "couldn't decrypt bytes" this is the first time in my life when i'm 100% sure of something and it's still not working, so i have lost over $300, multibit has really hurt me

[Mitch94541]

@Gary-rowe and Jim618, I seem to be having a similar issue with the "Provided AES key is wrong" error. I am using Multibit 0.5.18 in a Windows 8 PC. I have tried following the steps above, however, I can't seem to find the ".key" file or the ".wallet" file. All my transactions are correct, but I just can't access my Btc and am beginning to get concerned. I think that we may have taken a lightening strike close enough to mess with system as my B/u is messed up also. Is there anyway of re-creating files that you might be aware of? BlockChain info seems to be correct as is history. Thank you for your time

[Mitch94541]

Jim, It appears what may have happened was during one of the storms we have down here in Alabama a few files got, I guess you could call it "Re-arranged". I was able to find the file by locating it manually and then having a bit of working with it, got the password out as the path was different. Doubt if this will affect anyone else's issue, but what the heck.

Many Thanks as you pointed me in the right direction! Mitch

On Tue, Dec 29, 2015 at 4:31 AM, Jim Burton notifications@github.com wrote:

You need something with the private keys in so that would be any of:

• the wallet on your machine
• private key backups on your machine
• off machine backups.

If your wallet is encrypted you should have automatically exported private key exports from which you can recreate your wallet. Have a look in the help in 'File descriptions' as to where these are stored (It can be a hidden directory) and then try creating a new wallet and importing the private keys.

— Reply to this email directly or view it on GitHub https://github.com/bitcoin-solutions/multibit/issues/620#issuecomment-167762387 .

[Autoband86]

I am experiencing the same problem as tonyclifton13, I also have a password I am pretty sure of, and getting the AES key is wrong reply. I have a 2013 multibit 0.5.15 wallet, with one key file, and two backups. None of them open with the pass in Multibit, but do give the "Provided AES key is wrong" message.

In multibit the .key file won't open. If I decrypt the key with OpenSSL I get nonsense...

[Mitch94541]

Hello Autoband86, I am not sure why I was "CC'd" in this but I have experienced this one time about 3 years ago. Your "key" has been encrypted itself probably with PGP. Or you might have gotten a "worm/virus" infection. Do Not update multibit until it is resolved as you will lose any data in the encrypted file. try using any ambiguous password/key you might have used last year or earlier, even if it is one you used to create a "junk mail" account. after getting the info needed, update to Multibit 0.5.18 and update your key file.

Good luck, hope it works out for you! gpguy

On Tue, Jun 6, 2017 at 12:45 AM, Autoband86 notifications@github.com wrote:

I am experiencing the same problem as tonyclifton13, I also have a password I am pretty sure of, and getting the AES key is wrong reply. I have a 2013 multibit 0.5.15 wallet, with one key file, and two backups. None of them open with the pass in Multibit, but do give the "Provided AES key is wrong" message.

In multibit the .key file won't open. If I decrypt the key with OpenSSL I get nonsense...

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/keepkey/multibit/issues/620#issuecomment-306408463, or mute the thread https://github.com/notifications/unsubscribe-auth/APsXxsACWq-uXQ4EmR4FDcH9-sPzveX5ks5sBQOKgaJpZM4CtmXs .

[vamosrafa]

Mitch, Can you please clarify what you mean by PGP encrypted itself, I am having the same issue as Autoband, where I get a different error message when I enter in the password I believe to be correct. If were to reinstall the multibit version the key was encrypted with do you think this might solve the issue?

I am a layperson and not any kind of cyrptographer...

Thanks Spencer

[Mitch94541]

Hi Spencer, PGP="pretty good privacy", it is a fairly good encryption program that comes with it's own "public/private" keys for decrypting it's content. what I found, and it drove me nuts, was that I picked up a virus somewhere and it triggered a encryption with a different "key" which, unfortunately, is unknown. If memory serves, what I had to do was and I really don't remember all the steps, encrypt a new key with PGP and try unlocking the old one with the current "public" key. I think that is what I did, there is of course the naming/re-naming of the key file that goes on, but on this, I am not really clear on what/how I worked this out. The very last line of the file that you can't open might/might not tell you what happened and why it isn't opening. Multibit also has it's own encryption going on. That is why I recommend trying any ambiguous password you might have used when creating the key file.

Best of luck and I hope it works out and please try the password idea first. Mitch

On Tue, Jun 6, 2017 at 11:53 AM, vamosrafa notifications@github.com wrote:

Mitch, Can you please clarify what you mean by PGP encrypted itself, I am having the same issue as Autoband, where I get a different error message when I enter in the password I believe to be correct. If were to reinstall the multibit version the key was encrypted with do you think this might solve the issue?

I am a layperson and not any kind of cyrptographer...

Thanks Spencer

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/keepkey/multibit/issues/620#issuecomment-306582660, or mute the thread https://github.com/notifications/unsubscribe-auth/APsXxjIKeVa4CjoZ9Tt1tT2txzLh1igyks5sBaAjgaJpZM4CtmXs .

[fl0ppcom]

Good day, met same issuea couple of years ago. What I have now is my wallettutorial with and key file. Once upon the BTC rate is too high I have tried to recover.

What I have - my password is wrong (it was written on the paper) and stopped to open the wallet.

Nowdays I have found a tutorial on Multibit website same as abouve OpenSSL command. So what I have is - when I run the command it outputs: salt=FXXXXXXXXXXXXXXC key=DXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXC iv =FXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX8

P.S. It gives Success! with OpenSSL routines on 3 to 5 different passwords (with different salt/key/iv in result) .... which is weird ?

XXX of course are other signs ;)

And gives a recovery key file ...

So the thing is - when I try same password on the running wallet - it fails with 'Could not decrypt bytes'

What should I do ? The password I am sure 99,(9)% is exactly the right one.

Please advise .... I Promise to sent $300 to the one who gives the right solution on how to deal with that.

Also I have files at folder wallet-unenc-backup one is INFO other one is CIPHER and folder key-backup KEY file itself ... that is the one which I try with OpenSSL, but it looks as a lot of passwords gives a Success! result on it ... Am I missing something ? Am not sure as for now, but probably there was a version change at the moment from 0.5.14 to 0.5.18

[Mitch94541]

Good morning, First thing, Do Not reinstall the wallet software! That will create a new wallet and older keys will continue to get "could not decrypt" message. One thing to try (never sure this will work) is to create new key file. rename this one to "filename/new" and then tty naming the old file to the new name. Might work. other things is try "Any" old password you might have used, no matter how ambiguous and see if that works. If any of these works, don't worry about pay, just pass along the info and help others... Mitch

On Thu, Jun 8, 2017 at 6:56 AM, fl0ppcom notifications@github.com wrote:

Good day, met same issuea couple of years ago. What I have now is my wallettutorial with and key file. Once upon the BTC rate is too high I have tried to recover.

What I have - my password is wrong (it was written on the paper) and stopped to open the wallet.

Nowdays I have found a tutorial on Multibit website same as abouve OpenSSL command. So what I have is - when I run the command it outputs: salt=FXXXXXXXXXXXXXXC key=DXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXC iv =FXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX8

XXX of course are other signs ;)

And gives a recovery key file ...

So the thing is - when I try same password on the running wallet - it fails with 'Could not decrypt bytes'

What should I do ? The password I am sure 99,(9)% is exactly the right one.

Please advise .... I Promise to sent $300 to the one who gives the right solution on how to deal with that.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/keepkey/multibit/issues/620#issuecomment-307111067, or mute the thread https://github.com/notifications/unsubscribe-auth/APsXxhdktjxr4RgMHY9sTLa_XtL92X43ks5sB_1zgaJpZM4CtmXs .

[fl0ppcom]

Morning ;)

The thing is all that happened far ago 2013 , so Am not sure how all it was happening. But looks like it was updated to newer version. I mean set pass on 0.5.14 and after that dummy updated to 0.5.18 So it stopped working.

I have tried already to rut the wallet on 0.5.14 with no luck.

Will try later today your offered dances around the files ;) Thank you ...

[fl0ppcom]

Well ... what I have tried: I took the KEY file from KEY-BACKUP directory. I have created a new wallet. I run the IMPORT private keys ... I have chosen the KEY from above and put it as IMPORT FROM Now is happening weird thing as I wrote above: I have a set of 3 to 5 passwords which when I press UNLOCK give nothing (that are 5 separate different passwords ... ), when I put something else I got: Private keys unlock failed. Could not decrypt input string. But even with those five passwords abouve when I push IMPORT PRIVATE KEYS - it still says: The private key unlock failed. The error was : Could not understand the address in import file.

So am still have no idea how to deal on that .... ;(

[vamosrafa]

I have still not given up hope, it IS a corrupted private key that Multi Bit has somehow created, if you look here someone named HCP kindly created a tool to fix this issue on Multibit HD and Classic. It looks like the solution for classic is not working so far, however I will update here if he finds a solution. I am offering a bounty since the original devs seem to be long gone :(

https://bitcointalk.org/index.php?topic=1942459.0

[gary-rowe]

For the record, I'm no longer involved with the MultiBit project, but perhaps the following information can help people struggling with this situation.

If you are unable to unlock the wallet with the password then there are two possibilities:

1. You have the wrong password - more common that you'd think even when people swear blind that they're typing it correctly
2. The wallet/key file has become corrupted - very rare but exposes the fragility of encrypted files containing random private keys

Data does not exist unless it is in two places - ideally a local backup and a remote one. Even then files get corrupted just through hardware issues.

It was for the above reasons, and others, that the MultiBit development team strongly urged people for years to upgrade to MultiBit HD and the associated seed phrase which mitigates this situation entirely. Further, when creating keys and writing them out, MultiBit Classic checks that the data can be successfully read back in using the offered password.

What has happened?

In general when a file is AES encrypted there is a header section containing encryption specific data (key, salt, initialisation vector etc) then comes the main body of data. A corruption in the header section is a very serious problem as it renders decryption of the entire body almost impossible. A corruption in the body section allows for the wallet to be decrypted successfully but it could contain erroneous data.

What can I do?

Your first response should be to use reputable file recovery software. This will hopefully uncover early versions of wallet/key file backups and may undo the corruption through repair operations.

The quickest way to check the recovered files is to use OpenSSL as follows:

openssl enc -d -p -aes-256-cbc -a -in <ciphertext file> -out <plaintext file> -pass pass:<password>

The plaintext file should contain the text "keep your private keys safe" if it has decrypted correctly. Here is an example: https://multibit.org/help/v0.5/help_exportingPrivateKeys.html

Next, find a wallet/exchange that accepts private keys and sweep the recovered bitcoins into a hardware wallet protected by a seed phrase - such as Trezor.

That didn't work

If all you have is a damaged file your last hope is to try to work out how the file has been corrupted. If it is in the header section where the key, initialisation vector, salt etc are stored then that's bad news. It's going to take a lot of work to rebuild those.

If it is later then you could get a partial decrypt but have incomplete private keys. Bitcoin does have reasonable checksums so you could use a key recovery script to try various combinations until one gives a working checksum. You can then look up the associated address of the public key and check for your funds.

In either of the above cases of corruption you will need to be a very accomplished coder to successfully rebuild the files. You might want to consider sending it to a specialist service.

[fok35]

Hi there,

I get the "Provided AES key is wrong" error too. I am 100% sure that my entered password is correct. I get the error only when I enter that one specific password. I have the wallet and the associated key file.

I know that the project is dead, but after reading the entire thread, I read somewhere that a staff member provided his email adress to check the files. It would be great if he or another ex staff member could do that for me too. So is this possible? :)

Kind regards

[vamosrafa]

@fok35 I know how you feel man, it seems like from my interactions with the developer somehow the encryption header got messed up so the correct password is outputting a 94 character string which should be a 64 character private key. For me, it is a life changing amount of money locked up at current prices.

I have two wallets (one with empty private keys) so if anyone wants to help the few of us out in figuring this out I can offer a 5 digit USD bounty. (assuming the price doesn't crash)

[cryptoful]

I'm running into the same issue with a wallet created in December 2013. My friend accepted bitcoin for services, we created a wallet file for him, then I made a backup. A year or two later he says that he wants to 1: Make sure the password still works, and 2: Change the password. I advised him against this, but people can be stubborn. He changed the password, and now (2 years later) lost his wallet file. I gave him the backup I made for him, but he forgot the original password. We thought he had it considering that it was the only password to put out the AES key error, but:

Multibit Classic can't open the .wallet file with that password Multibit Classic can't open the .wallet.cipher with that password OpenSSL gives a bad decrypt error when using that password on the .key file (276:error:06065064:digital envelope routines:EVP_DecryptFinal_ex:bad decrypt:./crypto/evp/evp_enc.c:461:) MBexport also can't pull the key with that password.

Can someone confirm that if the password was correct, that at least one of these options would work? I have an old wallet file I am using to test all of these different ways to access it (to make sure my method is correct), and every single option works for me. (however I did notice OpenSSL NOT giving an error with a known bad password).

For everyone else, it might be worth trying MBexport if all the above options don't work. https://github.com/Multibit-Legacy/read-multibit-wallet-file

[Krivvan]

I'm helping someone out with the same issue with the apparently correct password outputting a 94 character string. I've tried importing all 64 character slices of that 94 character string (all encoded as actual 52 character private keys) but none of the private keys match up to the original address.

@vamosrafa Is it possible that any issue with the encryption header being messed up led to it not even being the private keys being encrypted? Would there just be no recourse in that case?

[Mat008]

Hello, Do we have a clear solution to the "Provided AES key is wrong" error message? I'm lost after reading all this information for a while.

Just to clarify, when I want to remove the password from my wallet, I get "Provided AES key is wrong" error message. If I use any wrong password, I get the usual "Could not decrypt bytes" error. Can someone please wrap this up for me? I'm not really a programmer and I really need help.

I can't believe Multibit is no longer supported. This is not fair...

Thank you very much!

[vamosrafa]

@Krivvan This is all far beyond my pay grade, my level of crypto expertise consists of installing SSL certs on a web server. It seems like with what @gary-rowe said that the encryption header data somehow got messed up.

Since the wallet is encrypted with AES-256 CBC is it possible that in a few years that encryption will be broken or weak enough to brute force the private key.

I am also assuming that if the encryption header is bad then the password is useless, however why does it give the different error message when you enter the correct password, and spit out the 94 character key in the multibit recovery tool?

[Mat008]

@clubshaft are you still there? I'd like to have more info about the procedure you describe above using Recuva (yes, 3 years ago...) Any help would be greatly appreciated. I have the same trouble you've experienced at that time. Please!

[Mat008]

@gary-rowe Since you were involved developping Multibit, may I suggest that you and your collaborators at the time fix the issue? There must be accountable people for this problem and it must be fixed once and for all. You and your team can't leave people that trusted you at the time, alone with the problem without being able to get their investment back. This is not acceptable.

[fok35]

@cryptoful Thank you for your reply, I gave your hint a try but ran into this error:

Do you know what's wrong here?

Kind regards

[Mat008]

• EDITED - dec 16 *

Sorry for the trouble, I found my real password using gurnec tool (thank$ payment sent!):

https://github.com/gurnec/btcrecover

The "Provided AES key is wrong" error message is related to somethong else, but not the actual password.

[caroksh]

Hi, I also have the same "Provided AES key is wrong" error with MultibitClassic wallet from 2013. I'm almost sure of my password. I've tried hundreds of different ones but only one gives me that error. And also, after trying this (a tool I got from github):

python decrypt_multibit_classic_walletkeys.py wallet_1.wallet I get the following error: File NOT Encrypted

Keys are encrypted This wallet file is encrypted, please enter its password:

Pubkey: 1M --------------------------------------------1r Traceback (most recent call last): File "decrypt_multibit_classic_walletkeys.py", line 215, in wallet = load_wallet(wallet_file, get_password) File "decrypt_multibit_classic_walletkeys.py", line 172, in load_wallet print("Privkey: " + bitcoin.encode_privkey(privkey, 'wif_compressed')) File "/usr/local/lib/python2.7/dist-packages/bitcoin/main.py", line 224, in encode_privkey return encode_privkey(decode_privkey(priv), formt, vbyte) File "/usr/local/lib/python2.7/dist-packages/bitcoin/main.py", line 237, in decode_privkey if not formt: formt = get_privkey_format(priv) File "/usr/local/lib/python2.7/dist-packages/bitcoin/main.py", line 217, in get_privkey_format bin_p = b58check_to_bin(priv) File "/usr/local/lib/python2.7/dist-packages/bitcoin/main.py", line 427, in b58check_to_bin assert bin_dbl_sha256(data[:-4])[:4] == data[-4:] AssertionError

There is only 1 password that gives this error, with any other it just keeps asking for the password again. So I'm pretty sure it's not a coincidence and that my password is OK.

As I can see there is quite a bunch of people with the AES key error. I've tried all what I've read here and in bitcointalk.org but nothing worked for the moment.

I have backups of .key and .wallet in 3 different laptops (2 of them since 2013) and in 2 USB's. I also have wallet.cipher file which doesn't open in MultibitClassic.

If anyone can help it would be really great, it's not a huge amount of money I have in the wallet, for the moment. But one day it can become bigger, so I'm trying to solve this before that happens.

Thank you very much for your help and interest.

[caroksh]

Sorry for the bold letters in my previous post. It was a mistake.

[Mat008]

@caroksh

Like many others, because this specific error message (Provided AES key is wrong), I thought I was entering the good password because any other password I was entering was giving "Could not decrypt bytes."

I was wrong.

Using gurnec tool helped me fing the actual password - so "Provided AES key is wrong" error message comes from who knows where...?

I strongly suggest you that you take the time to read and try gunrec procedure. it worked for me.

[Skripach007]

@Mat008 What was your problem? A typo or just a wrong password which you forgot?

In my case I'm 110% sure my password is the same I used to lock my wallet, because I generated it in mSecure and copy-pasted (I'm sure about what was pasted in the password field because I always check it by pasting on somewhere where its visible).