| commit | 8cd7bbf51408741d71926cf5a444beb8ff021909 | [log] [tgz] |
|---|---|---|
| author | David Benjamin <davidben@google.com> | Tue Mar 14 01:43:23 2017 -0400 |
| committer | CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org> | Sat Mar 25 21:25:30 2017 +0000 |
| tree | e18011278725a39f4e1a6fc49cf4aa1428d1b6b4 | |
| parent | 3cb047e56c3688c326cf894a4eeca42d0ec1b3b8 [diff] |
Push password encoding back into pkcs12_key_gen. With PKCS8_encrypt_pbe and PKCS8_decrypt_pbe gone in 3e8b782c0cc0d9621f622cf80ab1a9bcf442fa17, we can restore the old arrangement where the password encoding was handled in pkcs12_key_gen. This simplifies the interface for the follow-up crypto/asn1 split. Note this change is *not* a no-op for PKCS#12 files which use PBES2. Before, we would perform the PKCS#12 password encoding for all parts of PKCS#12 processing. The new behavior is we only perform it for the parts that go through the PKCS#12 KDF. For such a file, it would only be the MAC. I believe the specification supports our new behavior. Although RFC 7292 B.1 says something which implies that the transformation is about converting passwords to byte strings and would thus be universal, appendix B itself is prefaced with: Note that this method for password privacy mode is not recommended and is deprecated for new usage. The procedures and algorithms defined in PKCS #5 v2.1 [13] [22] should be used instead. Specifically, PBES2 should be used as encryption scheme, with PBKDF2 as the key derivation function. "This method" refers to the key derivation and not the password formatting, but it does give support to the theory that password formatting is tied to PKCS#12 key derivation. (Of course, if one believes PKCS#12's assertion that their inane encoding (NUL-terminated UTF-16!) is because PKCS#5 failed to talk about passwords as Unicode strings, one would think that PBES2 (also in PKCS#5) would have the same issue and thus need PKCS#12 to valiantly save the day with an encoding...) This matches OpenSSL's behavior and that of recent versions of NSS. See https://bugzilla.mozilla.org/show_bug.cgi?id=1268141. I was unable to figure out what variants, if any, macOS accepts. BUG=54 Change-Id: I9a1bb4d5e168e6e76b82241e4634b1103e620b9b Reviewed-on: https://boringssl-review.googlesource.com/14213 Reviewed-by: David Benjamin <davidben@google.com> Commit-Queue: David Benjamin <davidben@google.com> CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
BoringSSL is a fork of OpenSSL that is designed to meet Google's needs.
Although BoringSSL is an open source project, it is not intended for general use, as OpenSSL is. We don't recommend that third parties depend upon it. Doing so is likely to be frustrating because there are no guarantees of API or ABI stability.
Programs ship their own copies of BoringSSL when they use it and we update everything as needed when deciding to make API changes. This allows us to mostly avoid compromises in the name of compatibility. It works for us, but it may not work for you.
BoringSSL arose because Google used OpenSSL for many years in various ways and, over time, built up a large number of patches that were maintained while tracking upstream OpenSSL. As Google's product portfolio became more complex, more copies of OpenSSL sprung up and the effort involved in maintaining all these patches in multiple places was growing steadily.
Currently BoringSSL is the SSL library in Chrome/Chromium, Android (but it's not part of the NDK) and a number of other apps/programs.
There are other files in this directory which might be helpful: