When exponent bit length is a multiple of the window size and the top
word has only window bits in it, then n is shifted down by an undefined
value (size of a word). The n value is not used after this.
Check for this condition and don't attempt to shift n.
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.
Improve performance for ECC curves when all bits in words are used (mask
is 0).
On 64-bit platforms, improves performance for 256 and 384 bit curves.
On 32-bit platforms, improves performance for 224, 256, 384 bit curves.
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.
