Add regression tests to `test/evp_extra_test.c` that dynamically
discover all provided ciphers with non-zero IV length and verify
correct multi-step initialization semantics.
The EVP API permits key and IV to be supplied in separate
`EVP_CipherInit_ex()` calls (e.g. key-only followed by IV-only).
A recent bug (PR #29934, ASCON-
AEAD128) demonstrated that a
provider may silently ignore a key-only init, resulting in reuse
of a previously loaded key during a subsequent IV-only init.
To prevent similar regressions, this change introduces three
generic tests that automatically cover all IV-taking ciphers:
Verifies that:
- `init(key) → init(iv)`
- `init(iv) → init(key)`
produce identical ciphertext (and authentication tag for AEAD
ciphers) compared to single-call `init(key, iv)`.
Primes a context with `key1/iv1`, then re-initializes via
`init(key2) → init(iv2)` and verifies the output matches a fresh
`encrypt(key2, iv2)` operation, ensuring that no previously stored
key is reused.
Encrypts using single-call initialization and then decrypts using
multi-step initialization, verifying plaintext recovery. For AEAD
ciphers, this also exercises tag verification through the
multi-step path.
Ciphers are discovered using `EVP_CIPHER_do_all_provided()`,
requiring no maintenance when new IV-taking ciphers are added.
SIV mode is skipped due to its synthetic IV semantics. CCM mode
handling includes required length declarations.
This provides broad regression coverage for the provider
implementations that support multi-step EVP initialization.
Reviewed-by: Dmitry Belyavskiy <beldmit@gmail.com>
Reviewed-by: Paul Dale <paul.dale@oracle.com>
MergeDate: Thu Apr 16 07:08:17 2026
(Merged from https://github.com/openssl/openssl/pull/30141)