I have an AES256-encrypted file ssl.key and the script which sets up some software required this to be decrypted to plain text as ssl.plain.key as in

openssl rsa -in ssl.private.key -out ssl.plain.key

This will interactively ask for the password.

However, if the software is reconfigured there is no need to regenerate ssl.plain.key unless the originating ssl.key has changed. (For convenience's sake, I would like to not have to re-enter the password each time the settings are flushed during development.)

Can I verify that ssl.plain.key was derived from ssl.private.key without decrypting the private key again?

  • 2
    You can sign this key by itself (public part with private part) so this way you will know.
    – Aria
    Sep 22, 2016 at 21:33

2 Answers 2


Given that you use the openssl rsa command, I will assume that you refer to RSA private key files in the PEM format, encrypted using AES256. These look like:

Proc-Type: 4,ENCRYPTED
DEK-Info: AES-256-CBC,87FD3191BA64A020594BD81962FB092A


Unfortunately for you, all the base64-encoded data here is encrypted (emphasis mine):

The line beginning with Proc-Type contains the version and the protection on the encapsulated data. The line beginning DEK-Info contains two comma separated values: the encryption algorithm name as used by EVP_get_cipherbyname() and an initialization vector used by the cipher encoded as a set of hexadecimal digits. After those two lines is the base64-encoded encrypted data.

So it is impossible to obtain the original private RSA key without decrypting it.

Your configuration script must find other ways to detect that a RSA private key file has been updated (for example, by comparing timestamps, reading some markers, etc, etc.).

Since you mentioned SSL, note that certificates are bound to a RSA private key. In that case you can extract the public key from the RSA private key and certificate using:

openssl rsa -in server.key -noout -modulus
openssl x509 -in server.crt -noout -modulus
  • 1
    It could also be 'new' (since 1999, and default for many functions since 2010) encrypted-PKCS8 format, which has -----BEGIN ENCRYPTED PRIVATE KEY----- and not Proc-Type and DEK-Info. But if so that is also encrypted, and with a better PBE to boot. Sep 23, 2016 at 10:38
  • @dave_thompson_085 The commonly used openssl genrsa utility internally uses PEM_write_bio_RSAPrivateKey which always outputs the old format. As you noted, even with the new PKCS#8 format, the full contents is encrypted (convert with openssl pkcs8 -topk8 -in server.key -out server.pk8, verify with openssl asn1parse -in server.pk8)
    – Lekensteyn
    Sep 23, 2016 at 14:31

In general, the ability to determine whether encrypted content was derived from plaintext content is not good security, so without going into implementation details I'll just say this probably is not possible.

If you want to check whether an encrypted private key file has changed, I'd suggest something like the following:

At startup compare ssl.private.key with ssl.private.key.last. If they're the same, proceed. If they're different compute a new ssl.plain.key and overwrite ssl.private.key.last with ssl.private.key.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .