Found with the configuration running the unit test through valgrind.
% ./configure CFLAGS=-DNO_WOLFSSL_CIPHER_SUITE_TEST \
--enable-all --disable-fastmath --enable-debug --disable-shared
1. ssl.c: In wolfSSL_DSA_generate_key(), we initialize (and allocate)
all the parameters in the key (p, q, g, x, y), and then we generate a
key, initializes (and allocates) x and y, again. mp_clear them
first.
2. evp.c: When printing public keys, the temporary mp_int wasn't getting
correctly freed.
3. evp.c: When printing public keys, modified the utility functions to
return once with a do-while-0 loop.
A sizeof wasn't dereferencing a pointer using the sizeof the pointer and
not the actual struct. This is limited to setting the key for an AES
operation only when using SILABS SE2 acceleration.
Cortex builds needed # before number. Arm32 works with or without.
Thumb div_word needed to shift up if divisor too small (like other ARM
implementations).
Add support to ECIES for AES-256-CBC, AES-128-CTR, AES-256-CTR.
Added new API wc_ecc_ctx_set_algo() that sets the encryption, KDF and
MAC algorithms.
Cleanup formatting of ECIES code.
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.
* Fix for `EVP_CIPHER_CTX_flags`, which mapped to a missing function (broke openvpn)
* Added stack of name entries for ipsec/racoon support.
* Added `X509_STORE_CTX_set_flags` stub.
* Added PKCS7 NID types.
* Improved FIPS "SHA" logic in `test_wolfSSL_SHA`
* Added some uncommon NID type definitions.
* Expose the DH `DH_set_length` and `DH_set0_pqg` with OPENSSL_ALL
