> On Jan 14, 2018, at 10:26 AM, Chris B <cryptoassetrecovery@xxxxxxxxx> 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
