Re: [openssl-users] OpenSSL error message when decrypting Ethereum encrypted private key

[Chris B]

Hi Matt,

>If you *are* using 1.1.0 then the default digest was changed between 1.0.2
and 1.1.0.
Awesome thought, but I'm also using 1.0.2:

$ openssl version

OpenSSL 1.0.2k-fips  26 Jan 2017

(I also tried adding -md md5 to the previous command, but I got the same
error message).

Thanks,
Chris

On Sun, Jan 14, 2018 at 6:03 PM, Matt Caswell  wrote:

>
>
> On 14/01/18 15:26, Chris B 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 article
> > (https://www.reddit.com/r/Bitcoin/comments/3gwdge/
> importing_old_encrypted_private_keys/)
> > seems to describe a very similar EPK. 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"
> >
> > I have tried this same approach, but I'm getting an error:
> >
> > EVP_DecryptFinal_ex:wrong final block length
>
> What version of OpenSSL are you using. The quoted article was written 2
> years ago so definitely wasn't using OpenSSL 1.1.0. If you *are* using
> 1.1.0 then the default digest was changed between 1.0.2 and 1.1.0. Old
> OpenSSL "enc" output defaulted to md5. The current default is sha256:
>
> https://www.openssl.org/docs/faq.html#USER3
>
> Try adding "-md md5" onto your command line.
>
> Matt
>
>
> >
> > Here's an example:
> >
> > /usr/bin/openssl enc -d -aes-256-cbc -a -in enc_private_key.txt -out
> > recovered.key -pass pass:TheBig7ebowski
> >
> > And here's the output:
> >
> > bad decrypt
> >
> > 140220549330848:error:0606506D:digital envelope
> > routines:EVP_DecryptFinal_ex:wrong final block length:evp_enc.c:581:
> >
> > I'm not sure how to interpret that output. I could interpret it as:
> > o Your system for decrypting the password is perfect, but: this is not
> > the right password.
> > o There's something wrong with the EPK -- its length must be a multiple
> > of the AES block length.
> > o There's something wrong with the unencrypted private key -- its length
> > must be a multiple of the AES block length.
> > o Something else entirely
> >
> > Can anyone help me understand how to interpret this error message?
> >
> > Thanks,
> > Chris
> >
> >
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] OpenSSL error message when decrypting Ethereum encrypted private key

[Matt Caswell]

On 14/01/18 15:26, Chris B 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 article
> (https://www.reddit.com/r/Bitcoin/comments/3gwdge/importing_old_encrypted_private_keys/)
> seems to describe a very similar EPK. 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"
> 
> I have tried this same approach, but I'm getting an error:
> 
> EVP_DecryptFinal_ex:wrong final block length

What version of OpenSSL are you using. The quoted article was written 2
years ago so definitely wasn't using OpenSSL 1.1.0. If you *are* using
1.1.0 then the default digest was changed between 1.0.2 and 1.1.0. Old
OpenSSL "enc" output defaulted to md5. The current default is sha256:

https://www.openssl.org/docs/faq.html#USER3

Try adding "-md md5" onto your command line.

Matt


> 
> Here's an example:
> 
> /usr/bin/openssl enc -d -aes-256-cbc -a -in enc_private_key.txt -out
> recovered.key -pass pass:TheBig7ebowski
> 
> And here's the output:
> 
> bad decrypt
> 
> 140220549330848:error:0606506D:digital envelope
> routines:EVP_DecryptFinal_ex:wrong final block length:evp_enc.c:581:
> 
> I'm not sure how to interpret that output. I could interpret it as:
> o Your system for decrypting the password is perfect, but: this is not
> the right password.
> o There's something wrong with the EPK -- its length must be a multiple
> of the AES block length.
> o There's something wrong with the unencrypted private key -- its length
> must be a multiple of the AES block length.
> o Something else entirely
> 
> Can anyone help me understand how to interpret this error message?
> 
> Thanks,
> Chris
> 
> 
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] OpenSSL error message when decrypting Ethereum encrypted private key

[Chris B]

>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


000   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-us...@dukhovni.org> wrote:

>
>
> > On Jan 14, 2018, at 10:26 AM, Chris B 
> 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 < U2FsdGV0X185M9YAa/27pmEvFzC5pqLI4xWrA6ouGVCx0EeJ9s8DzeGuBtYJPDCK
> Dy0m80yvHdQYDMPa+Hwv2JPbuGJNoUMhFWpcQW1VF+EAy0tYb7Wtv2+IRWZzcpsE
> 8e2a
> END
> 000S   a   l   t   e   t   _   _   9   3 326  \0   k 375 273 246
> 020a   / 027   0 271 246 242 310 343 025 253 003 252   . 031   P
> 040  261 320   G 211 366 317 003 315 341 256 006 326  \t   <   0 212
> 060  017   -   & 363   L 257 035 324 030  \f 303 332 370   |   /ؓ
> 100   **   ۸  **   b   M 241   C   ! 025   j   \   A   m   U 027 000
> 120   \0 313   K   X   o 265 255 277   o 210   E   f   s   r 233 004
> 140  361 100 232
>
> This does indeed look a lot like "openssl enc" output:
>
> $ echo foobar | openssl enc -aes256 -pass pass:foobar | od -c
> 000S   a   l   t   e   d   _   _ 263   f 243  \0 242   ~ 031   3
> 020  266 035   Y 310 367 300 366 264 247   :   $   s 236 266   4 340
> 040
>
> 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
>
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Fwd: Information to detach a BIO from fd

[Michael Wojcik]

> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf
> Of Michael Richardson
> Sent: Saturday, January 13, 2018 16:34
>
> > On 12-Jan-2018, at 6:45 PM, Michael Wojcik
> >  wrote:
> >> Don't create the BIO immediately. Use getpeername on the socket
> >> descriptor and check that against the list. Only create a new SSL
> >> object and BIO if it's not an already-established client.
>
> That only works with TCP.

Yes, of course. I realized this myself when I saw the followup question. Post 
in haste, repent in leisure...

Thanks for the correction.

-- 
Michael Wojcik 
Distinguished Engineer, Micro Focus 



-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] OpenSSL error message when decrypting Ethereum encrypted private key

[Viktor Dukhovni]

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

Re: [openssl-users] OpenSSL error message when decrypting Ethereum encrypted private key

[Chris B]

Hi Rich,

Thank you very much for the reply.

I get the same error message using -aes256 as -aes-256-cbc

/usr/bin/openssl enc -d -aes256 -a -in enc_private_key.txt -out
recovered.key -pass pass:TheBig7ebowski


bad decrypt

140383648536480:error:0606506D:digital envelope
routines:EVP_DecryptFinal_ex:wrong final block length:evp_enc.c:581:

Thanks,
Chris

On Sun, Jan 14, 2018 at 10:39 AM, Salz, Rich via openssl-users <
openssl-users@openssl.org> wrote:

> For CBC the encrypted text will be a multiple of the cipher size.  So your
> use of CBC is wrong.  The quoted post uses aes256; you were using aes-cbc
>
>
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
>
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] OpenSSL error message when decrypting Ethereum encrypted private key

[Salz, Rich via openssl-users]

For CBC the encrypted text will be a multiple of the cipher size.  So your use 
of CBC is wrong.  The quoted post uses aes256; you were using aes-cbc

-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] OpenSSL error message when decrypting Ethereum encrypted private key

[Chris B]

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 article (
https://www.reddit.com/r/Bitcoin/comments/3gwdge/importing_old_encrypted_private_keys/)
seems to describe a very similar EPK. 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"

I have tried this same approach, but I'm getting an error:

EVP_DecryptFinal_ex:wrong final block length

Here's an example:

/usr/bin/openssl enc -d -aes-256-cbc -a -in enc_private_key.txt -out
recovered.key -pass pass:TheBig7ebowski

And here's the output:

bad decrypt

140220549330848:error:0606506D:digital envelope
routines:EVP_DecryptFinal_ex:wrong final block length:evp_enc.c:581:

I'm not sure how to interpret that output. I could interpret it as:
o Your system for decrypting the password is perfect, but: this is not the
right password.
o There's something wrong with the EPK -- its length must be a multiple of
the AES block length.
o There's something wrong with the unencrypted private key -- its length
must be a multiple of the AES block length.
o Something else entirely

Can anyone help me understand how to interpret this error message?

Thanks,
Chris
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] SSL Cert serial number non-uniqueness impact

[Salz, Rich via openssl-users]

The combination of (issuer,serial#) is the only way to get a unique identifier 
for a certificate.  Lots of software depends on certs being uniquely 
identifiable.  What happens if that assertion is not true?  Some things will 
break.  What?  Well, it depends on the software, and which certs are 
“duplicates” and so on.  There’s no way to know, really.  Just don’t do it.

For example, if cert-A has a keypair and cert-B has a keypair, then site-B 
could send a TLS chain with cert-A and while it would look correct, the 
connection would fail.  This is silly if B is doing it, but it is a DoS attack 
if a man in the middle does it.
 

-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] SSL Cert serial number non-uniqueness impact

[Jochen Bern]

On 01/14/2018 12:07 PM, pratyush parimal wrote:
> I read  from several sources that the serial number of a cert MUST be
> unique within a CA. But could someone explain what would happen if the
> serial number was not unique?

Certificate Revocation Lists (CRLs) identify invalid certificates by
means of a) the CA keypair that issued it (the pubkey being represented
in the signature) and b) the serial number, *not* pubkey / DN / ..., of
the invalid cert. If that's not unique, revoking one of the affected
certs will have the effect of revoking them all.

Regards,
-- 
Jochen Bern
Systemingenieur

www.binect.de



smime.p7s
Description: S/MIME Cryptographic Signature
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] SSL Cert serial number non-uniqueness impact

[pratyush parimal]

Hi everyone,

I read  from several sources that the serial number of a cert MUST be
unique within a CA. But could someone explain what would happen if the
serial number was not unique?

Would it cause SSL connections to fail in some manner? I think I'm a little
unclear about the "purpose" of the serial number in the first place. Is it
just something the CA uses to keep track of what/how many certificates it
has issued, or does it play a part in the SSL connection itself?

Thanks in advance!
Pratyush
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users