# What are the implications of an encrypted private key being released?

An application owner at my organization requested a java keystore to be built around specific parameters and provide them with both the JKS and pkcs12 versions of the keystore. Weeks later and after many changes they were troubleshooting some issues. The application admin, not thinking of the security implications, blasts an email with the output of the OpenSSL command: pkcs12 -info -in .

In the output of that command the first key listed shows.

-----BEGIN ENCRYPTED PRIVATE KEY-----
blahblahblahblahblah
-----END ENCRYPTED PRIVATE KEY-----

To me this looks nuclear and appears to expose the private key. My recommendation initially is to burn the entire keystore and start over rekeying everything. As this is a significant amount of work I wanted to be sure my reaction was accurate. It does say Encrypted so perhaps as long as the password is still secure maybe we're okay? I'm pretty solid on OpenSSL and keytool but this slips past my expertise. Can anyone here help me define the exposure for my mangement?

• The key is as secure as the password used to encrypt it (is my spontaneous guess). – SEJPM Apr 28 '17 at 18:23
• Is the password "i have no hat" or is it "9um1ecDpRbAihsoKB7GCWM24UlJk"? – David Schwartz Apr 28 '17 at 20:41

Since the encrypted key file is (potentially) leaked, and adversary is able to run an offline dictionary attack against your key. So you have to answer the question: Is the strength of the password used to encrypt the key, weaker than the strength of the key itself?

So what you should do, is calculate the strength (entropy) of your password (KeePass can do this, for instance) and compare it to current strength estimations for the itself (RSA 2048 has 112 bits, for example). If the password's result is weaker then the key, you should drop it and revoke the certificate.

The PKCS#12 standard is simply a way to transport "stuff" described by other PKCS standards in one convenient bundle, particulary PKCS#8 private keys (let's call it "your key") in "Shrouded" mode: this is your key, encrypted using further keys (let's call that the transport key) derived from a password as specififed in PKCS#5. The way "your key" is encrypted with the "transport key" is unfortunately geared more towards interoperability than absolute security.

So unless you explicitly take control of the cipher chosen, your program is going to be conservative to be compatible - OpenSSL still defaults to 3DES used to shroud your key in the PKCS#12 file. This is considered obsolete in many contexts.

So, this depends on how much you trust 3DES to be unbreakable before your key itself expires/is no longer useful. Even if it is only obtained (cracked) after the nominal expiry date, your key can be used to retroactively sign things that may appear as if it happened before your key expired. Unless you're a very attractive target, spending any serious resources on this is unlikely, but then that's not quite the point.

Unless you've got other mitigations (which are very specific and unlikely), I wouldn't trust your key to be safe, and it's a great opportunity to test (or develop) your key revocation procedures.

• If you run: \$ openssl pkcs12 -noout -info ...you shoudl come across a line similar to this: Shrouded Keybag: pbeWithSHA1And3-KeyTripleDES-CBC, Iteration 2048 That's your info to determine how how breakable the keybag is. – Liam Dennehy Apr 29 '17 at 21:12
• This is a good answer for the PKCS12, but the Q is about (email containing) the output from pkcs12 (without -export) which reads the p12 and (for version 1.0.0+) outputs the key as a new, separate p8 PEM block, using PBKDF2 with 2048 iterations and defaulting to 3DES-CBC unless you specify otherwise and it doesn't look like that person did. You can see/verify the encryption details of the output key (or any other p8), though less simply, with asn1parse. In practice the password(s) will be broken eons before (3key) 3DES is. – dave_thompson_085 Apr 30 '17 at 0:51
• What I tried to point out is that pkcs12 isn't a unique key transportation scheme, merely a container for pkcs8 and other objects, and those standards determine the security (skipping password quality/privacy, iterations etc), so that's where the answer is derived. Good point on the fresh password though (ie without --export): if the admin is just rushing through and accidentally mailing an encrypted bag around, I doubt he's put much thought into the password. – Liam Dennehy May 1 '17 at 13:21