When compiling with the CFLAG -m32, sp_c32.c is used and not sp_c64.c.
The build system cannot detect that this is a 32-bit platform and to use
sp_c32.c.
The SP code detects which implementaiton to use and sets defines that
enable the code in sp_c32.c or sp_c64.c.
ENABLED_64BIT, 64-bit platform, was on by default, which is not always
true.
By making ENABLED_64BIT not default then the decision of which SP C
files to include in the build had to change to not being the other.
That is, sp_c64.c is not included when the configuration line explicitly
enables 32bit and sp_c32.c is not include when the configuration line
explicitly enables 64bit.
* whitespace in src/ssl.c, tests/api.c, wolfssl/openssl/fips_rand.h.
* clang-analyzer-core.StackAddressEscape from llvm-15 clang-tidy, in tests/suites.c:execute_test_case().
* bugprone-suspicious-memory-comparison from llvm-15 clang-tidy, in src/internal.c:DoSessionTicket() and src/ssl.c:wolfSSL_sk_push().
ASM code is dividing by top half of divisor. If this value is very small
then bad results are calculated.
Moved the divisor up by a quarter of the width if top quarter of divisor
is 0.
In `wolfSSL_EVP_CipherInit`, `ctx`'s `ivSz` field isn't being accounted for.
A common OpenSSL EVP AES-GCM flow looks like this:
- `EVP_CIPHER_CTX_new`
- `EVP_EncryptInit_ex`
- `EVP_CIPHER_CTX_ctrl` with command `EVP_CTRL_GCM_SET_IVLEN` to set the IV
length to 16 (AES block size) instead of the default 12
- `EVP_EncryptInit_ex` again to set the key and IV
- `EVP_EncryptUpdate` however many times
- `EVP_EncryptFinal`
In fact, we test this flow in our unit test `test_wolfssl_EVP_aes_gcm`. However,
in our implementation, the second call to `EVP_EncryptInit_ex` unconditionally
resets the IV length back to 12. This doesn't cause a test failure because
decryption has the same problem, so both sides of the equation have the same
wrong view of the IV.
The solution is to preserve the IV length in wolfSSL_EVP_CipherInit if ctx->ivSz
is non-zero. Otherwise, use the default of 12 (`GCM_NONCE_MID_SZ`).
This was discovered by a user migrating to the compatibility layer. As I
mentioned, it isn't exposed by our testing. It is exposed if you try to use the
same key and IV with OpenSSL and compare the resulting ciphertext with wolfSSL.
They won't be the same and thus won't interoperate.
David Garske
Chris Conlon
tmael
Eric Blankenhorn
Sean Parkinson
John Safranek
TakayukiMatsuo
Daniel Pouzzner
Anthony Hu
Kosmas Valianos
Lealem Amedie
Marco Oliverio
Hayden Roche