No, it does not. I just thought, that the password or the all or subset of the passwords are correct, then the permutations with repetitions would decrypt the secret.key.
So, if it could not decrypt, then it means either:
the password or passwords are not correct or
some additional things have been added during upgrades by Daedalus to alter the correct passwords. Like new line (\n in Mac\Linux or \r\n, white spaces appended to the correct password or using it as hex string of ASCII representation (“123” → “313233” etc.) r similar changes to alter the correct passwords at some point or points at updates.
Wallet name can be anything and has nothing to do anything with the updates. I mean it can be changed, but it does not really matter as secret.keys do not contain the name of the wallet.
I tested the secret.key you sent me and it’s a proper one, meaning the passwordHash’ password is the same with the encryption key’s password. So, I am not looking for those kind of secret.keys, but those who have the passphrase and/or the proven right password (moved the fund out to Shelley using that password) and have invalid empty password based passwordHash.
sorry. Wallet name was not entered. The wallet name is “Migrated Wallet”. I am concerned that it was written that it was migrated.
What I want to know is why password hashes disappeared? Or is the password hash data left in another folder?
Password is not set in daedalus0.8. I have since updated to 0.12. We are skipping over 0.9, 0.1 and 0.11. I think that’s likely what caused the password hash to disappear. Are there any possible errors when updating from 0.8 to 0.12? ?I didn’t set a password when I made 0.8. So, at this time, I think that it was uploaded without a password.
2020.1.13 log
At this time, the password hash is “true”. There must have been a password hash. But the wallet name was “Migrated Wallet”. It is strange that the wallet name cannot be read.
The wallet ID at this time and the wallet ID when importing secret.key with the new Daedalus are different. Should it be different?
You cannot encrypt the master secret key with an empty passphrase. That’s why I told you that something must have happened.
A new line? As it’s not empty bit [10] or [13,10] array etc. It can happen as a normal ENTER is usually a ‘\r’ or ‘\r\n’ in an Operating system that could’ve passed to the underlying encryption algorithm.
That’s why this kind of data would be very beneficial to examine to figure out what has happened during the migration.
As it has two data sets, one state before migration and one after migration.
Did it just remove the passwordHash and not touch the master secret?
Did it remove the passwordHash and even did something with the master secret e.g., encrypted with a new line?
Because, my permutation-based recovery would work in the case of 1, assuming the user knows the password(s).
But it would not matter, as my permutation-based recovery would work if it just removes the passwordHash and you know all the passwords you set in that time.
That’s why I say if the passwords are correct and it cannot decrypt the key, then something has happened too.
As the encryption function DO NOT encrypt/decrypt anything if an empty string is given. Just copy it over.
So this statement is either false from KtorZ-bug report back in 2018:
“no password” (secret keys are actually encrypted with an empty passphrase)
Or the encryption alg encrypt/decrypt data with empty password, which is false and can be verified very easily.
What other possibilities could be are that the password is changed somehow, for example it converted to UTF-8 or similar or as I mentioned the \n’ or ‘\r\n’ or mixed of any changes that alter a password or an empty password to some non-empty one.
No, it must be the same as the wallett ID must be the same as it’s generated from the public key and the chain code.
If it’s changed, then something has happened, e.g. the public key or the change code is altered.
It can have impacts on the private key. But, KtorZ had a wrong assumption based on encrypting w/ an empty password.
The easiest way the check the master key ingegrity is just comparing the stored public key (in the master secret key) with a newly generated one from the master private key, where both must be the same (if the private key ins not encrypted).
So, if it’s not, then the private part of the master secret key is encrypted.
But, your situation is different, it says hasSpendingPassword no, but the private key is encrypted.
You say:
You did not set password for daedalus v0.8
You upgraded directly to v0.12.1 after 24-jan-2019
your log shows spendingPassword is set on 5th of May (was it the same v0.12.1 at update time or the v0.13.1 in some later time than the v0.12.1 update?
Then how spendingPassword could disappear in later versions? As you say it say no spendingPassword now.
Because the old wallet id is based on the original public key, while the imported one is calculated from the encrypted’s public key at importing time. Though it wont alter the public key in the secret key after it’s imported. That’s why you see those addresses.
There is no any strange in it as the byron addresses (random index based ones) differs from shelley (deterministic HD wallet based on BIP-44) ones. Which means, that the wallets need to process all the byron addresses (as they’re not deterministic addresses), meaning all UTxOs that contain byron addrs in the chain to figure out whether an address belong to that wallet (public key based which is never encrypted part of the encrypted secret key)
But, it seems that the log is mixed from different sources/users etc.
So, I am not sure who owns that secret.key as it seems to me leaked out.
There is no point in trying to brute force it when the used encryption passwords are unknown.
It’s just a waste of time with no understanding the fundamentals of cryptography.
The presence of various devices in the log is due to testing on various PCs.
I grabbed the data from my old computer and tried it on another computer. I also tried it on MAC and windows. And I consulted with many people.
Was there any scene where secret.key was corrupted by looking at the log?
It’s a pity that I can’t decrypt even though I have the password.
I will restore the trash of the computer where the old Daedalus was installed and test whether an even older secret.key appears.