tree 027a42cbc343f8373d3a1ac05ddf797eaa35cfe2
parent 294ab9730c570213b496cfc2fc14b3c0bfcd4bcc
author David Benjamin <davidben@google.com> 1739489985 -0500
committer Boringssl LUCI CQ <boringssl-scoped@luci-project-accounts.iam.gserviceaccount.com> 1740073271 -0800

Support PBES2 schemes in PKCS12_create

We were able to decrypt them, but not create them. This adds support for
creating them. They are a little goofy because OpenSSL has two different
conventions for specifying PBES schemes. Decryption just requires
parsing out the AlgorithmIdentifier structure embedded in the input,
while encryption requires some way for the caller to specify the
algorithms.

PKCS#12 files could be encrypted with two different PBES (password-based
encryption scheme) schemes from PKCS#5: PBES1 and PBES2. Where PBES1 was
fully described by a single OID, PBES2 is itself parameterized by a KDF
and a cipher[*].

OpenSSL first added PBES2 encrypting support in
https://github.com/openssl/openssl/commit/8eb57af5fed7a133cdb2a968081c355249c00b98,
but only added it to PKCS8_encrypt, for encrypting PKCS#8 blobs. This
was early so they were willing to break their public APIs. They chose a
convention where you passed both a NID and an EVP_CIPHER. If the NID was
-1, the cipher would be used instead with PBES2, hardcoding PBKDF2 with,
at the time, HMAC-SHA1. We implement this API.

Later, OpenSSL added PBES2 encrypting to PKCS12_create in
https://github.com/openssl/openssl/commit/b0e69a05008531c51180cf8fc10694871d33eaa8,
but now backwards compatibility does not allow adding an EVP_CIPHER
parameter to PKCS12_create. OpenSSL instead decided that if the NID
matched a known EVP_CIPHER (e.g. NID_aes_256_cbc), it would implicitly
pick PBES2, the way -1 and an EVP_CIPHER specified it before.

This CL implements that behavior. I've opted to keep the PKCS8_encrypt
calling convention and just translate to it for now. But we really
should pick a less chaotic calling convention (we're C++ now, so we
could even use std::variant...) at least for the internals.

For now, the defaults are still at the values they were in older
OpenSSL. I've filed https://crbug.com/396434682 to track that. (Only
reason to do it separately is to have something easily revertible and
decide when to do the low-but-nonzero-risk change.)

As an aside, OpenSSL later further complicated this (still not
documenting anything) with
https://github.com/openssl/openssl/commit/5693a30813a031d3921a016a870420e7eb93ec90

There was no way to specify the PBKDF2 PRF function. So they overloaded
the NID parameter, to specify that. Now the decision tree is:

- If the NID is -1, PBES2 with the cipher and the default PBKDF2
- If the NID is a PRF algorithm, PBES2 with the cipher and that PRF as
  the PBKDF2 PRF
- Otherwise, PBES1 with the NID specifying the PBES1 scheme

This CL does not implement that extra feature. This calling convention
is a mess.

[*] To be honest, I'm not sure what PBES2 even specifies. The operation
in RFC 8018, Section 6.2.1 is pretty much meaningless. Use the selected
KDF to derive a key, then use the selected cipher to encrypt it. PBES2
does not actually come with any choices of KDF or cipher, you have to
pick them when formulating a PBES2 scheme. PBES2 appears to just
describe sticking the two together generically.

Fixed: 394337104
Change-Id: I1380b339d398783ee65cde3d9f526b9d8fc1c2d4
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/76307
Commit-Queue: David Benjamin <davidben@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>