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?

user45979
  • 11
  • 2

1 Answers1

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.

dave_thompson_085
  • 9,759
  • 1
  • 24
  • 28
  • 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 05 '16 at 01: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 07 '16 at 21:48