Title: BIP38 enc key verification techinque - checksum vs salt sha256 Post by: MikeJ_NpC on February 13, 2020, 09:55:49 AM Is there a proper way to verify a BIP38 key to my wallet?...... Meaning, ...
If i compare the checksum it passes, (but) the 4 bytes of the salt; should match 4 bytes of the SHA256 hash of the public address? correct? however the result i get is they dont match. So which method is valid here? .... ??? ??? -side comment: if it was a BIP39 redone into the BIP38 would this then cause the mismatch on the salt sha256? :o As an example assuming the encoding is properly done. the bip38 spec here: https://github.com/bitcoin/bips/blob/master/bip-0038.mediawiki#Proposed_specification. Notice this line: "4 bytes: SHA256(SHA256(expected_bitcoin_address))[0...3], used both for typo checking and as salt". This is failing. Also as a control it passes just fine for test cases on bitaddress.org. (vs) The checksum doesnt throw any mismatch, where as if i change it to another key, it then throws invalid Not sure the proper way to verify a BIP38 key.. in the least i like to know which is applicable for verification.... :-\ ??? (( no i dont have my passphrase, (yeah have an idea) so if there is a way to derive it, i would appriciate the help, or if someone wants to give it a shot.)) Hope this makes sense, thank j00s. ;D ;D Title: Re: BIP38 enc key verification techinque - checksum vs salt sha256 Post by: pooya87 on February 14, 2020, 03:53:21 AM Is there a proper way to verify a BIP38 key to my wallet? it is unclear what you mean by this even with the follow up. if you want to "import" it in your wallet it has to support BIP38 first then all you have to do is enter the base58 string starting with 6P and your password. you can also use a tool (offline) like https://github.com/pointbiz/bitaddress.org to decrypt and convert it to a normal WIF then import that. if you want to "verify" it yourself then this is how its done: Code: 6PRVWUbkzzsbcVac2qwfssoUJAN1Xhrg6bNk8J7Nzm5H7kxEbn2Nh2ZoGg Code: decoded = 0142c0e957a24ad357fafb81c71f8375a9a4d0ac02bad5f6c87c4b459fabe34c0c314b33708ec3 ✔ decoded length = 39 ✔ first two bytes = 0x0142 ✔ third byte (flag) = 0xc0 = 0b11000000 ✔ based on first two bytes and flag => non-EC-multiplied [] 4 bytes salt = 0xe957a24a ✔ 32 byte remaining [] the rest is decryption using AES, XORing blocks and deriving the address and checking it with the 4 byte salt. Quote the 4 bytes of the salt; should match 4 bytes of the SHA256 hash of the public address? correct? however the result i get is they dont match. you are doing something wrong, i can't know without looking at what exactly you did. you can compare your steps with the example above.So which method is valid here? .... ??? ??? the WIF of the example is: 5KN7MzqK5wt2TP1fQCYyHBtDrXdJuXbUzm4A9rKAteGu3Qi5CVR its address is: 1Jq6MksXQVWzrznvZzxkV6oY57oWXD9TXB Code: SHA256(SHA256(UTF8(1Jq6MksXQVWzrznvZzxkV6oY57oWXD9TXB) = Quote -side comment: if it was a BIP39 redone into the BIP38 would this then cause the mismatch on the salt sha256? BIP39 creates mnemonics and BIP39 encrypts private keys. they can't be mixed together!Quote (( no i dont have my passphrase, (yeah have an idea) so if there is a way to derive it, i would appriciate the help, or if someone wants to give it a shot.)) you can't "derive" your password from the encrypted result! you have to know it. |