> On Jan 14, 2018, at 10:26 AM, Chris B <cryptoassetrecov...@gmail.com> wrote: > > I'm trying to help someone recover his password for an older format ethereum > encrypted private key (EPK). My plan has been to use his best guess at the > password to brute force the actual password. > > The EPK is a 132 character string, and it looks something like this: > U2FsdGV0X185M9YAa/27pmEvFzC5pqLI4xWrA6ouGVCx0EeJ9s8DzeGuBtYJPDCKDy0m80yvHdQYDMPa+Hwv2JPbuGJNoUMhFWpcQW1VF+EAy0tYb7Wtv2+IRWZzcpsE8e2a > > (That is: 128 ASCII digits and/or letters, plus three "+" and a "/".)
This input is base64 encoded: $ openssl base64 -d <<END | od -c U2FsdGV0X185M9YAa/27pmEvFzC5pqLI4xWrA6ouGVCx0EeJ9s8DzeGuBtYJPDCK Dy0m80yvHdQYDMPa+Hwv2JPbuGJNoUMhFWpcQW1VF+EAy0tYb7Wtv2+IRWZzcpsE 8e2a END 0000000 S a l t e t _ _ 9 3 326 \0 k 375 273 246 0000020 a / 027 0 271 246 242 310 343 025 253 003 252 . 031 P 0000040 261 320 G 211 366 317 003 315 341 256 006 326 \t < 0 212 0000060 017 - & 363 L 257 035 324 030 \f 303 332 370 | / ؓ 0000100 ** ۸ ** b M 241 C ! 025 j \ A m U 027 000 0000120 \0 313 K X o 265 255 277 o 210 E f s r 233 004 0000140 361 100 232 This does indeed look a lot like "openssl enc" output: $ echo foobar | openssl enc -aes256 -pass pass:foobar | od -c 0000000 S a l t e d _ _ 263 f 243 \0 242 ~ 031 3 0000020 266 035 Y 310 367 300 366 264 247 : $ s 236 266 4 340 0000040 Except that for some reason the "d" in "Salted" is a "t". Funny that these are the voiced and unvoiced variants of the same consonant, but note also that the ASCII code for 'd' = 0x64 and 't' = 0x74, so this is a 1 bit change. Any chance this is data corruption? > > This article > (https://www.reddit.com/r/Bitcoin/comments/3gwdge/importing_old_encrypted_private_keys/) > seems to describe a very similar EPK. In that sample, the base64-decoded data starts with "Salted__" as expected. > The author of that post decrypted their key with the following command: > > openssl enc -in FILE_OF_KEYS -a -d -salt -aes256 -pass pass:"PASSWORD_HERE" Hard to say whether that's correct, rather depends on the format of "FILE_OF_KEYS". You could try a dictionary attack on the actual 132-byte string, after base64-decoding, provided it is not corrupted. -- Viktor. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
