mirror of
https://github.com/wolfSSL/wolfssl.git
synced 2026-01-28 06:02:22 +01:00
b850cc89b0
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.