"Provided AES key is wrong" when decrypting wallet #620
Comments
|
I also try to import them in blockchain . I create there a wallet and try to import but that is not working annymore |
|
We haven't stolen your bitcoins. Let's go through this step by step to help you unlock your wallet. Can I ask you to keep your responses to this issue to help me and others keep track of your progress. You may want to remove personally identifying information from your posts (don't reveal your balance and so on). Next, can you verify that you've read the password recovery help article: https://multibit.org/en/help/v0.5/help_lostOrForgottenPassword.html Note to readers in 2020 and laterThis is an immense thread, filled with various dead ends. Please see this summary #620 (comment) |
|
if someone can tell me wich files I needed than I use a new hard disk with a clean instalation and run this disk in usb external modus to run get data back ntfs . ps: yes sir I read that but like I say I know my password ! if I type it wrong that I get the message could not decrypt . . . . . . that is 100% wrong pass . but AESkey is wrong sorry but that is not my wrong . |
|
OK, I need to establish a baseline of what you've already tried to recover the wallet. Can you tell me when the wallet was first created and in which version of MultiBit it was done? |
|
yes 2014-05-07 00:17:** I did my first transfer with that wallet . therefore I use an other wallet but that one is still ok . |
|
multibit vers 15 ► now I use vers 18 from last saturday after my lost coins ! ! back then I created that wallet 10 min later I make the password for it . is it posible that the recovery file that I have is before I enter an pass to it ? the last good files are from september . but they give bold an error " NUL" |
|
Can you verify that you are using 0.5.18 as the wallet creator? It is very unlikely that the AES encryption key would have been mangled since MultiBit will check that it can decrypt the wallet with the given password before returning with a positive message. When you add a password to a wallet MultiBit Classic will go over any backups it can find and apply the encryption to protect any previously unprotected keys. Unless your backups are outside of where it would normally expect to find them they should all be encrypted. Here is some detailed technical information on the encryption used: https://github.com/jim618/multibit/wiki/Export-and-limited-import-of-private-keys At this stage I would recommend that you switch to using OpenSSL to attempt decryption since it will be faster than through the MultiBit UI. You should target the .key file. You should also pursue the possibility that you might have accidentally mistyped your password. It is definitely worth using the script in the password article referenced earlier to explore a variety of combinations rapidly. You can run the script using cygwin if you're on Windows. |
|
multibit vers 15 ► now I use vers 18 from last saturday after my lost coins ! ! |
|
if I type it wrong than I always get coulsd not decrypt .. . . . . but i know the pass I use it + 20 times from 05/2014 till last saturday |
|
maibe I must uninstall version 18 and get back to 15 ? |
|
What message is OpenSSL giving you when you attempt to decrypt using: Obviously you'll substitute your own values. Don't rewind back to 0.5.15. I want to be sure that the problem is with the key file. You're adamant that you are typing in the correct password but that decryption is failing. That indicates a corrupted file but we have to be sure. |
|
are you related to the software sir ? |
|
Yes, Jim is the primary developer of MultiBit Classic and I'm the secondary. I've asked Jim to keep an eye on this thread and he'll probably take over later since I have limited time available today. |
|
I now find the file multiwallet-qt.md is this helpfull ? search for the key file now |
|
Don't know that file so it's probably not relevant. If you need to locate the .key file this article will assist you: https://multibit.org/en/help/v0.5/help_fileDescriptions.html |
|
have it . yesterday I rar it with pass and there I get it now becouse the other is missing . ok here is my key located can you give me the exact code j:\nul_error.key |
|
this whas the original key name bv-20140507000410.key and thgis is the wallet bv-20140507000410.wallet |
|
that ssl stuff is chineese for me lol |
|
Now that you have a
Change OpenSSL will attempt to decrypt the file and will tell you if it is successful. The decrypted keys will be placed in You can see the key file format here: https://multibit.org/en/help/v0.5/help_exportingPrivateKeys.html |
|
I have win 7 64 bit do I need to download the win 64 vers ? |
|
Sounds right. It'll tell you if it has problems. |
|
@clubshaft You don't need to download a Win 64 version - the Windows installer is 32 bit and should work fine |
|
ok I uninstall then becouse it not work |
|
no #611 have nothing to do with my problem ! my password is not working and it is the right one ! ! ! ! ! |
|
Provided AES key is wrong ! I have the key file and ssl is instal now how to run it so I can encrypt like you explane to me |
|
Gary's post starting "Now that you have a .key file do the following (I've made the instructions step by step for Windows):" explains using OpenSSL step by step. Please take the time to go through the suggestions step by step. It is the same process effectively as doing an Tools | Import private keys but on the command line. Also, in your original post you don't explain where you got your private key file export from. Note that your password is case sensitive and must match exactly (i.e. the same sort of hyphen, quote mark etc) or you won't be able to decrypt that file. |
|
I've been working on this problem for the past few weeks and here are some definitive results as a result of a very detailed analysis across multiple versions of the code bases of MultiBit and Bitcoinj (the underlying library):
If one runs a password cracker over a MultiBit wallet there are multiple instances where the message "Provided AES key is wrong" is seen. When one provides the correct password the correct public key is derived from the decrypted private key. In addition, I myself have sworn blind that I used one password to encrypt a wallet only to find that I actually used another one entirely unrelated. Our human memories are truly terrible. So given the above, what can be done?
Note that MultiBit does not use simple password hashing so a rainbow attack is useless. Instead a cracking tool would need to use the same code as present in MultiBit/Bitcoinj and work through the different candidates. This is a deliberately slow process (30-100 guesses per second offline) so any good guesses at existing passwords greatly reduce the search space. |
|
Thanks for this @gary-rowe. I am most interested in your last paragraph. Or maybe I misunderstood your post. |
|
@omnivorist MultiBit Classic uses Scrypt as a key derivation function with parameters N=16384, R=8, P=1. This has the effect of forcing a time constraint on processors in order to generate the resulting hash which is then used as the actual key for the AES (CBC padded) encryption of the private keys. These parameters were considered good for 2013 and a bit weak for 2017 and much less suitable for 2020 onwards. However, I should point out that this only applies to the keys within a If a key export has taken place (found in an encrypted The command line to access this file (usually in the openssl enc -d -p -aes-256-cbc -a -in encryptedwallet.key -out decryptedwallet.txt -pass pass:yourpasswordand is much faster to decrypt. A possible cracking script for MultiBit Classic
|
|
@gary-rowe fantastically helpful input there. I think I've been down these avenues thoroughly but I'll put aside some time to double check this weekend. Would you mind also listing the exact version of OpenSSL you are using? I know that the default parameters changed in between versions. E.g. an older version used the default |
|
@gar-rowe: First, like @markburns, I'd like to thank you for the really helpful and full response you have made to this discussion. I should explain that I spent much of my career developing software in C++ so I have an understanding of computers and software. All the same, I have very little knowledge of encryption, python and these kinds of configuration environments so I am grateful for all the help you can give. I have read your post very carefully and have a few questions and observations of my own. I don't understand your first paragraph about Scrypt and the Protobuf serialisation format. Maybe this doesn't apply to my situation. I have a number of .wallet files but I have some .key files also and, so far, I have been concentrating on using these in an attempt to rediscover my (lost) password. The idea then would be to use the password to export the private keys and to import these into a new, supported wallet app. By the way, the version of Multibit I am using is 0.5.17. I loaded the wallet in 2014. I am using btcrecover (mentioned by other contributors to this post) to try to discover my password. In order to give myself some confidence, I have created a new (empty) Multibit wallet, and protected it with a password. I then take the .key file associated with this wallet and run btcrecover on it - and btcrecover succeeds in finding the correct password. This suggests that the general approach is sound but I am interested to know if you think my confidence is justified, given the time that has elapsed since I created my first key files. After reading your post I felt I should try using openssl as you suggest and installed a version on my PC. openssl enc -d -p -aes-256-cbc -a -in test.key -out decryptedtest.txt -pass pass:<my_password> None of this makes much sense to me. If you feel there is something to be gained by using openssl, I am willing to put the effort in to getting it working but I could use some help. One more (maybe irrelevant) observation:
The earliest dated key file is only about half the size of the others. Is this what you would expect to see if it corresponded to an empty wallet? ONCE AGAIN: I really appreciate your help with this All the best, |
|
@markburns When generating the example file I used the latest version of MultiBit Classic. The encryption library is The version of OpenSSL I'm currently using on my test machine is I should add that occasionally the script above will report a successful decrypt even when it didn't (Provided AES key is wrong rears again). This version may work better (same rules for #!/bin/bash
echo Usage: apply-guesses.sh [password CSV] [key file]
echo Password file: $1
echo Key file: $2
for password in $( awk -F , -v OFS=' ' '{print $123}' $1 ); do
echo ------
echo Attempting: $password...
openssl enc -d -p -md md5 -aes-256-cbc -a -in $2 -out recovered.key -pass pass:$password
if [ $? -eq 0 ];
then
grep 'T\d\d:\d\d:\d\dZ$' recovered.key
if [ $? -eq 0 ];
then
echo "Success!";
break;
else
echo "Garbage"
fi
else
echo "Failed";
fi
echo ------
done |
|
@omnivorist I'll try to answer your questions as best I can
There are two different mechanisms at play for storing encrypted private keys: the It is much faster to test a password against a
Yes, that sounds fine. The
The default hash used to derive keys from a password changed between OpenSSL 1.0.2 and OpenSSL 1.1.0. Try this:
MultiBit Classic does support using different passwords for the |
|
Thanks again @gary-rowe. I will carry on but I may not reply for a while. You have given me plenty to think about. |
|
I have the same problem: Happened! Could pick up through the btcrecover program. If anyone needs help, write. I also have more than 20 mining farms |
|
@gary-rowe Thanks very much for your responses here. It helped me make real progress in saving the private key. I'm stuck on a new step and really hope you can give some suggestions: In Dec 2013 I exported a wallet and key file, both encrypted, from multibit classic. Now I only remeber the key password, and have been trying to decrypt it lately. I installed a multibit classic 0.5.17 from web (now I know this might be dangerous). I set a new wallet, tried to import the encrypted key, and input the password. It didn't say "could not decrypt input string" as in the case I used any other wrong password, but it said "could not understand address in import file". This case was the same as @fl0ppcom once said in this topic. Then I tried to decrypt it externally; finally found the command ?躠磱Q?39'ad"t鉼!?狡 I was told in another forum that it looked like a binary file. So I tried to encode it with base64 or base58, imported the result or its substrings from beginning in Electrum, but it seemed none of them were valid address. I had no idea if it was designed like this in the 2013 version or there was something wrong when the key was exported, and if there is some way to covert that plain text to a private key in common form. Could you tell me something about this? Thanks and best wishes! |
|
@constchange What you have there is a failed decrypt (similar in nature to the "Provided AES key is wrong" situation). Encryption does not guarantee integrity, only confidentiality. This is why the MultiBit wallet format contains the expected public keys so that the integrity of the private key can be verified after decryption. To see the actual wallet format, try running the To verify integrity we can make use of the fact that all encrypted MultiBit private key exports have an ISO-8601 UTC format timestamp ( |
|
@gary-rowe Thank you for reply! Yes I have newly exported a few encrypted empty keys from multibit classic 0.5.17 to verify the validity of openssl decryption, and all of them had the same format as the empty abc123 demo key. (The only strange thing was that the dates of their timestamp are all incorrect, e.g., all in 2014 or 2015 while it is 2021 now. However, they could be decryption successfully and imported to Electrum. So it might be not important.) So, I wonder the "failed decrypt" you mentioned means that my old key file is alright while I decrypted it with a wrong password and got a wrong plain text occasionally,
|
|
@constchange The discrepancy with the timestamp is that it depends on where in the synchronisation process MultiBit was when it exported the keys, and also when it thinks it first saw the key. So the timestamp is just an optimisation rather than an absolute. During the private key export process, MultiBit Classic would read the file back in to check that it could be decrypted with the given password so it's unlikely that the file was corrupted at that moment, but could have decayed over time. Perhaps a file recovery/repair tool could be used if the original storage device is still available? |
|
@gary-rowe |
|
@constchange You may want to continue working with the exported wallet file as it is much quicker to test a decryption than the If the Directly attacking the |
@gary-rowe me again, having another crack at this. used here: here there is an iteration count of 1024. https://github.com/Multibit-Legacy/multibit/search?q=ITERATIONS&type=code a grep of the codebase doesn't yield anything further (just in case it's an issue with GH's search) Where do you get 'iteration count of 1'? |
|
@markburns That's a great investigation, and thanks for taking the time to dig deep into it. You've actually uncovered quite an interesting situation. Before going further, let's recap. The MultiBit openssl enc -d -aes-256-cbc -a -in cipher.txt -out plain.txt -pass pass:aTestPasswordwhich in 2013 would have meant:
So, OpenSSL back in 2013 had a default Password Based Encryption (PBE) process which was rather weak. It was essentially "combine the password with the salt and perform a single round of MD5 to get the key." However, in the /**
* number of times the password & salt are hashed during key creation.
*/
private static final int NUMBER_OF_ITERATIONS = 1024;
...
PBEParametersGenerator generator = new OpenSSLPBEParametersGenerator();
generator.init(
PBEParametersGenerator.PKCS5PasswordToBytes(convertToCharArray(password)),
salt,
NUMBER_OF_ITERATIONS);This is misleading and the source of the confusion. What is actually happening is the You can check this for yourself by running the I hope this helps, and perhaps offers some relief that previous efforts in decrypting haven't been in vain due to an incorrect number of iterations. If you're able to decrypt the example exported key referenced earlier in this thread using |
Hello! Some months ago help with multibit.key file to one of my friend. Maybe can also help to you, if you give me little more details. My telegram: https://t.me/labokho |
|
obviously, your problem is caused by the bug. can only decrypt the keys manually offline. you can reach https://www.Btc2doge.com |
Do you still need recovering your multibit wallet? |
|
@clubshaft > Provided AES key is wrong ! I have the key file and ssl is instal now how to run it so I can encrypt like you explane to me just asked the guy who helped on my wallet, you are correct, the AES is wrong. this is bug of the wallet. not your password problem. but also a small chance is caused by password encryption proocess when you make backup. this is bug. you may reach stephen. www.btc2doge.com wish you succeed. |
@vamosrafa This is caused by the multibit bug, rather than a password issue. www.btc2doge.com can help this if you still have the files. |
|
@markburns were you ever able to derive a password for your .key file. I'm having similar fun so just wondering if you had success or how you achieved that success exactly. |
I was not ever able to do anything. I have MBC 0.5.17 with full wallet files onboard available (.key, wallet,.cipher) And now I read here but have no any idea what to try else. I have tried openssl, tried recovery scripts but nothing works.
But actually everyone who mentioned bug - provide contacts of some suspicious persons (on telegram) or websites (websites are shutdown currently), so I am not sure at all which way to dig further. P.S. To add some motivation to anyone involved in a past development:
|
|
No I never did.
One day I will have another try maybe.
…On Thu, 4 Apr 2024 at 00:53, KryptoKicks ***@***.***> wrote:
@markburns <https://github.com/markburns> were you ever able to derive a
password for your .key file. I'm having similar fun so just wondering if
you had success or how you achieved that success exactly.
—
Reply to this email directly, view it on GitHub
<#620 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AIIIADPXRFDRIXNB26IFIRDY3SI6TAVCNFSM4AVWMXWKU5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TEMBTGU4DEMJQGE3A>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
Very wise to be cautious about people offering help. I still think it's possible there was a bug. Last time I looked into it there was a missing version from the downloads on the original site. Which would have been the release around the time I had my wallet. At this point in time though trying to rebuild it all with all the dependencies is like archaeology. I know one of the original developers has asserted that it's not the case, and that backup and restore works correctly across versions. And without wanting to be disrespectful to him if that is indeed true. It could still be the case that there is a bug and there's also a theoretical chance that it's a well obfuscated one. Whilst there are unrecovered funds, only the original developers can know the truth. And the chance of multiple people having cosmic rays distort their backups seems in the same realm of unlikely as a nefarious actor concealing a way of locking up people's funds and separately offering the helping hand to unlock them for a fee or to steal. So whilst it is unknown all possible paths forward seem open. Including fallibility of memory and cosmic rays flipping bits on backups etc. It would be nice to really draw a line under this one day but if the truth is it's people's memories at fault then I think this thread could carry on endlessly. Unless someone finds a bug and shares their solution (instead of offering suspicious help privately) |
|
@gary-rowe attempted to help me but was unsuccessful. Obviously people with BTC locked in a multibit classic wallet are now thinking about cracking the wallet again (myself included). I still find it strange that quite a few people swear they have the correct password and it does not work, but maybe it is just the case that we want to believe that. I came across a person in the Bitcoin talk forum who posted back in 2022 saying that Multibit inserted Unicode characters in the password to decrypt the file. The vanupied person has since disappeared. There is also another person claiming they have figured out some error related to the encryption who seems more doxxed than the people on that forum. I would like to keep hope alive, it is gut wrenching to see that life chaning amount of money in this old software. |
From my experience, we humans have terrible memory, so in the vast majority of cases, the user is indeed remembering the wrong password. That being said, I did investigate Multibit's codebase because, well, bugs do happen. And I did find an encoding bug, which is why I wrote my blog post at https://pascal-bergeron.com/en/posts/multibit-corrupt-password/. To be clear, however: this bug may affect you only if you are trying to decrypt the .key file with a password cracker and if your password contains a character outside the ASCII charset. It shouldn't prevent you from decrypting the .wallet with a password cracker or from decrypting the wallet through Multibit's user interface. In other words, this is a very niche bug. Still, it proves that bugs do exist within Multibit's codebase, so I hope it will motivate other programmers to inspect it further.
I have tried to reproduce this bug, to no avail, unfortunately. I will let you know guys if that changes. |
|
I'd just like to add to @PascalBergeron1993's excellent work in identifying an issue with non-ASCII passwords. It does give some hope for fixing some classes of So what's going on? If a user enters a non-ASCII password then the most significant byte is dropped leading to a different encryption key than what is expected for the exported Here's a worked example:
How did this slip through? The test cases surrounding this situation in MultiBit Classic didn't pick it up as they didn't fully exercise the end-to-end encryption cycle with And what can be done? You'll need a tool that can:
It's not particularly polished, but here is some code to help others along. It's basic Java that shouldn't need any external libraries. I can't attach it due to GitHub's restrictions on code. package org.example.bitcoin;
import java.io.BufferedReader;
import java.io.File;
import java.io.IOException;
import java.io.InputStreamReader;
import java.nio.file.Files;
import java.util.List;
import java.util.regex.Matcher;
import java.util.regex.Pattern;
import static java.lang.System.exit;
/**
* <p>Convert UTF-8 password into openssl command allowing for most significant byte stripping</p>
* <br/>
* <h2>Arguments</h2>
* <ul>
* <li>0: Full path to ciphertext file (e.g. example.key)</li>
* <li>1: Full path to plaintext file (e.g. example.key.pkain)</li>
* <li>2: The password as originally typed (e.g. Москва)</li>
* </ul>
* <br/>
*/
public class OpenSSLKeyFixer {
private static final char[] HEX_ARRAY = "0123456789ABCDEF".toCharArray();
// Fast hex formatter from StackOverflow (see https://stackoverflow.com/a/9855338)
private static String bytesToHex(byte[] bytes) {
char[] hexChars = new char[bytes.length * 2];
for (int j = 0; j < bytes.length; j++) {
int v = bytes[j] & 0xFF;
hexChars[j * 2] = HEX_ARRAY[v >>> 4];
hexChars[j * 2 + 1] = HEX_ARRAY[v & 0x0F];
}
return new String(hexChars);
}
public static void main(String[] args) {
if (args == null || args.length < 3) {
System.err.println("Arguments: [ciphertext file] [plaintext file] [password]");
exit(1);
}
// Build up an openssl command with higher order byte stripping applied
StringBuilder cliBuilder = new StringBuilder("openssl enc -d -p -aes-256-cbc -a -md md5 -in \"" + args[0] + "\" -out \"" + args[1] + "\" -pass pass:");
StringBuilder processBuilder = new StringBuilder("openssl enc -d -p -aes-256-cbc -a -md md5 -in " + args[0] + " -out " + args[1] + " -pass pass:");
char[] password = args[2].toCharArray();
// Build up the different versions of the OpenSSL command
for (char ch : password) {
byte b = (byte) ch; // Note that MSB will be dropped
// Restore the potentially mangled char
char strippedChar = (char) b;
// Process will correctly handle the input stream
processBuilder.append(strippedChar);
// CLI command will need escaping to reliably work in a shell
if (b < 48 || (b > 57 && b < 65) || (b > 90 && b < 97) || (b > 122 && b < 127)) {
// Use $(printf '\x00') to print the unprintable
byte[] bytes = new byte[1];
bytes[0] = b;
cliBuilder
.append("$(printf '\\x")
.append(bytesToHex(bytes))
.append("')");
} else {
cliBuilder.append(strippedChar);
}
}
// Command built so report to user for use on command line
String cliCmd = cliBuilder.toString();
System.out.println(cliCmd);
Pattern pattern = Pattern.compile("(T\\d\\d:|:\\d\\dZ)");
// Run local openssl as a process
try {
Process p = Runtime.getRuntime().exec(processBuilder.toString());
p.waitFor();
if (p.exitValue() != 0) {
// Read the stderr from the process
BufferedReader reader = new BufferedReader(new InputStreamReader(p.getErrorStream()));
String line = reader.readLine();
while (line != null) {
System.err.println("> " + line);
line = reader.readLine();
}
} else {
// Read the stdout from the process (as an input)
BufferedReader reader = new BufferedReader(new InputStreamReader(p.getInputStream()));
String cmdline = reader.readLine();
while (cmdline != null) {
System.out.println("> " + cmdline);
cmdline = reader.readLine();
}
System.out.println("No error reported");
File deciphered = new File(args[1]);
if (!deciphered.exists() || !deciphered.isFile()) {
return;
}
List<String> decipheredLines = Files.readAllLines(deciphered.toPath());
for (String line : decipheredLines) {
Matcher matcher = pattern.matcher(line);
if (matcher.find()) {
// Very likely have a cracked key - slam the brakes on
exit(0);
}
}
}
} catch (IOException | InterruptedException e) {
e.printStackTrace();
}
}
}I'm not a Java programmer how can I run this? Probably best to ask someone to do it for you, or try the manual approach described later. Don't enter your password into an online tool. What does the output look like? The really tricky part here is the creation of a terminal/shell compatible command line that correctly escapes difficult characters. For the openssl enc -d -p -aes-256-cbc -a -md md5 -in "/example.key" -out "example.key.plain" -pass pass:$(printf '\x1C')$(printf '\x3E')A$(printf '\x3A')20Note the use of embedded Is there a manual approach? Yes, the code will do a lot of work for you, but you can do this manually if you're willing to spend a bit of time fiddling with the Unicode character tables
I can't guarantee that all the above will work but it does go some way to solving a potential issue with MultiBit Classic |
and others
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 ███
The text was updated successfully, but these errors were encountered: