[openssl-users] OpenSSL error message when decrypting Ethereum encrypted private key
Chris B
cryptoassetrecovery at gmail.com
Sun Jan 14 22:36:25 UTC 2018
>Any chance this is data corruption?
Brilliant! You caught me. Although this key is encrypted I wasn't
comfortable making it public on the interwebs. So, I randomly changed
several of the characters. If I run openssl base64 -d... on the *actual*
key it does indeed begin with Salted__:
$ openssl base64 -d -in enc_private_key.txt | od -c
0000000 S a l t e d _ _
>You could try a dictionary attack on the actual 132-byte string, after
base64-decoding,
>provided it is not corrupted.
This is basically what I was trying to do, although I was simply running a
few hundred thousand strings that are related to the best guess password,
rather using a dictionary attack.
Is there a better command to proceed with a brute force attack than this
one?
/usr/bin/openssl enc -d -aes-256-cpc -a -in enc_private_key.txt -out
recovered.key
As I understand:
- openssl enc -d => decrypt using openssl
- -aes-256-cpc => use the AES 256 CPC algorithm
- -a => base64 decrypt
- -in => read the encrypted string from enc_private_key.txt
- -out => write the unencrypted string to recovered.key
I tried running openssl in two steps: first doing the base64 decoding, then
decrypting with -aes256, which I believe is functionally the same as the
command mentioned above:
$ openssl base64 -d -in enc_private_key.txt | openssl enc -d -aes256 -out
recovered.key
enter aes-256-cbc decryption password:
bad decrypt
139845090879392:error:0606506D:digital envelope
routines:EVP_DecryptFinal_ex:wrong final block length:evp_enc.c:581:
Which brings me back to the original question. Does anyone know how to
interpret "EVP_DecryptFinal_ex:wrong final block length"
Thanks!
-Chris
On Sun, Jan 14, 2018 at 11:21 AM, Viktor Dukhovni <
openssl-users at dukhovni.org> wrote:
>
>
> > On Jan 14, 2018, at 10:26 AM, Chris B <cryptoassetrecovery at 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/27pmEvFzC5pqLI4xWrA6ouGVCx0EeJ
> 9s8DzeGuBtYJPDCKDy0m80yvHdQYDMPa+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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20180114/cc850a22/attachment-0001.html>
More information about the openssl-users
mailing list