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

[Chris B]

Thank you to everyone that has weighed in on my question.  Unfortunately, I
have yet to find an answer that I'm fully satisfied with.

I'm trying a different approach: I would like to create a sample encrypted
Ethereum private key that shares the same 132 character PEM format as the
string I'm trying to decrypt.  I can then attempt to decrypt that string
with an incorrect password, and see if I get the EVP_DecryptFinal_ex:wrong
final block length error.  Does that make sense?

Here's my basic approach.  I'm starting with Vincent Kobel's excellent
"Create a Full Ethereum Wallet, Keypair and Address" article (
https://kobl.one/blog/create-full-ethereum-keypair-and-address/)

He creates a 132-character PEM formatted unencrypted private key with this
command:

openssl ecparam -name secp256k1 -genkey -noout

Unless I have completely failed at reading the man page correctly, there's
no way to assign a password from the ecparam command.

I write the 132 character unencrypted private key (not the -----BEGIN/END
EC PRIVATE KEY-----  characters) to a file named sample_pk.pem and I
encrypt it with openssl:

openssl enc -e -aes-256-cbc -a -in sample_pk.pem -out sample_epk.pem -pass
pass:secret


I now have a 256 character encrypted private string.  (Note, the string
length is 256 characters whether I use AES-128 or AES-256.  That's probably
obvious to all of you, but it wasn't to me).

If I decrypt that string with the correct password


openssl enc -d -aes256 -a -in sample_epk.pem -out recovered.key -pass
pass:secret


I get my original unencrypted private key back.  Excellent!


However, If I decrypt that string with an incorrect password:

openssl enc -d -aes256 -a -in sample_epk.pem -out recovered.key -pass
pass:secr3t

I get a new error message:

EVP_DecryptFinal_ex:bad decrypt


And, that message does not match the EVP_DecryptFinal_ex:wrong final block
length error message I was hoping to get.


I think that all that I have proven with this exercise is that the original
unencrypted private key was:


   - not a 132 character PEM formatted unencrypted private key
   - and/or
   - it was not encrypted using the -aes-256-cbc encryption algorithm

So, on to the question!  Can anyone help me figure out how to create an
Ethereum private key such that when it is encrypted it is a 132 character
long PEM formatted string?

Alternately, is there a process for taking an encrypted string, and
"backing in" to the details of how it was created?  (ie what algorithm,
etc?)

Thanks,
Chris


On Mon, Jan 15, 2018 at 2:01 PM, Chris B <cryptoassetrecovery at gmail.com>
wrote:

> Hi Daniel,
>
> >Option #1 from the possibilities you mentioned below seems to be the
> most logical to me.
> Thank you, that's very helpful.
>
> Thanks,
> Chris
>
> On Mon, Jan 15, 2018 at 1:29 PM, Sands, Daniel <dnsands at sandia.gov> wrote:
>
>> On Sun, 2018-01-14 at 18:26 -0500, Chris B wrote:
>>
>> 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).
>>
>>
>> Option #1 from the possibilities you mentioned below seems to be the most
>> logical to me. If you use the wrong key, the padding data in the last block
>> will also be decrypted to the wrong values, so the padding block check will
>> fail. The padding is a necessary part of decryption because it needs to
>> know how much plaintext is actually represented by that last block.
>>
>>
>> > 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
>>
>>
>>
>> --
>> 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/20180118/29fd9fcf/attachment-0001.html>