-
Notifications
You must be signed in to change notification settings - Fork 788
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
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 openssl/openssl@8eb57af, 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 openssl/openssl@b0e69a0, 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 openssl/openssl@5693a30 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 <[email protected]> Auto-Submit: David Benjamin <[email protected]> Reviewed-by: Bob Beck <[email protected]>
- Loading branch information
Showing
6 changed files
with
138 additions
and
78 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters