| commit | 1ce2ec71c3e5563fcebc08bbe67ad5f11add02d8 | [log] [tgz] |
|---|---|---|
| author | David Benjamin <davidben@google.com> | Sun Nov 27 18:34:32 2022 -0500 |
| committer | Boringssl LUCI CQ <boringssl-scoped@luci-project-accounts.iam.gserviceaccount.com> | Tue Nov 29 20:02:20 2022 +0000 |
| tree | a2325abceb076322846e02baaa19f2c43b755e19 | |
| parent | 7f7599a7264ddde9c720db49135ec919593789e2 [diff] |
Give cipher tests a common entrypoint. The main FileTest callback didn't support invalid ciphertexts, while the Wycheproof one did but reimplemented a lot of logic to discover variations. Rework this a bit so we have a single TestCipher function that's agnostic to the FileTest setup. The Operation enum gains a kInvalidDecrypt mode to specify that the ciphertext is invalid. As part of this, we tighten up the test This is to make the later changes easier: 1. We don't have any negative tests for EVP_CIPHER's tag check at all! We only test it for EVP_AEAD right now. Now TestCipher can express this. 2. The weird EVP_Cipher API has no tests. It has a weird calling convention that was easier to test if calling code knew whether to expect success or failure. Previously, kInvalidDecrypt was implemented by checking if DoCipher failed, which makes it harder to embed success/failure-specific assertions. Along the way, I've made each function responsible for running through the input once, with separate TestCipherAPI and TestLowLevelAPI helpers. Otherwise we have to reset the spans and keep track of the state of intermediate values. Bug: 494 Change-Id: Ieab87c0c76586aefeb596cc90edd4910ff1b962f Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/55387 Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: Adam Langley <agl@google.com>
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.
Project links:
There are other files in this directory which might be helpful: