1

I would like to make a note that I have read all of rfc 7292.

I am trying to decrypt encrypted private key in a pkcs#12 pfx file.

The private key is enveloped within pkcs#8 shrouded key bag.

The OID preceding encrypted private key represented as an octet string is

pbeWithSHAAnd3-KeyTripleDES-CBC  OBJECT IDENTIFIER ::= {pkcs-12PbeIds 3}

which I would take to assume that the private key is encrypted with Triple DES

CBC, and password derivation method is pbe.

RFC 7292 describes a "General Method" in section B.2 and B.3, and appendix C

clearly notes

here, we specify a few more, all of which use the procedure detailed in Appendices B.2 and B.3 to construct keys (and IVs, where needed).  

Instructions in the first paragraph of Appendix B states, however,

 Specifically, PBES2 should be used as encryption scheme, with PBKDF2
   as the key derivation function.

So in this pfx file, is the private key is encrypted with a symmetric key derived from the general method described or is it more likely that it is encrypted by a symmetric derived by pbkdf2 ?

Also, PKCS#5 does not describe how IV is derived from PBKDF2. Where can I find specification?

1

The first paragraph of RFC7272 appendix B, which is the second paragraph in original [RSA PKCS#12v1.1] (http://www.emclink.net/collateral/white-papers/h11301-pkcs-12v1-1-personal-information-exchange-syntax-wp.pdf), recommends that PBES2/PBKDF2 from PKCS#5v2+ be used, but this is only 'should' (not even RFC2119 upper-case SHOULD) and the scheme of appendices B and C (all in B in original) can be used, and is used by the specific OID you quote.

Note RFC7292 as published has two typos in B.2 step 6 A, (only) one of which was previously errata-ed. I have reported this to the rfc-editor and they will fix the erratum; until then you should use the original v1.1 (or v1). Or alternatively the code in a working and available implementation like OpenSSL (or its forks) or NSS or Java.

RFC7292 C (or PKCS#12v1+ B.4) says

The PBES1 encryption scheme defined in PKCS #5 provides a number of algorithm identifiers for deriving keys and IVs; here, we specify a few more, all of which use the procedure detailed in Appendices B.2 and B.3 to construct keys (and IVs, where needed).

As stated, these schemes derive both the key and the IV if needed (which it is for 3TDES-CBC), using different 'diversifier' inputs as described in B.3 and referenced in B.2.

In contrast PKCS#5 PBES1 derives both the key and IV from a single PBKDF1 operation, while PBES2 uses PBKDF2 to derive only the key; the IV if any is chosen separately, and carried in the parameters field of the AlgorithmIdentifier for PBES2.

  • Thank you very much, your answer really clarifies it. I have one more question though, does EVP_BytesToKey() in openssl use the scheme in rfc#12? I set EVP_CIPHER as des_ede3_cbc and EVP_MD as sha1. Openssl man pages suggest it uses the scheme in PKCS#5 v1.5 – user45979 Feb 5 '16 at 1:28
  • @user45979 (I assume you mean PKCS#12; RFC#12 was way back during ARPAnet.) EVP_BytesToKey implements an extension of the scheme of PKCS#5 through v1.5, which is retronymed PBES1 and PBKDF1 in PKCS#5v2+ (and deprecated); for the hash and cipher combinations defined by PBES1 (which does not include TDES) EVP_BytesToKey is identical to PBKDF1. Which, for clarity, is similar to but not the same as PKCS#12 appendix B (and C for the RFC). – dave_thompson_085 Feb 7 '16 at 21:48

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.