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.
openssl ecparam -name secp256k1 -genkey -noout
If I decrypt that string with the correct password
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
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!
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:
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@xxxxxxxxx> 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,ChrisOn Mon, Jan 15, 2018 at 1:29 PM, Sands, Daniel <dnsands@xxxxxxxxxx> 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 versionOpenSSL 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
-- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
