The comments around AES_decrypt() and AES_encrypt() in crypto/aes/aes_core.c state: "in and out can overlap". Does this only apply to the pure C version of AES, or to any or all assembly implementations as well?
Re: Regarding the use of EVP_aes_256_cbc_hmac_sha256, EVP_rc4_hmac_md5 and AES_encrypt
On 17/04/2019 19:36, Guido Vranken wrote:
> First question:
> How should AAD data be supplied to ciphers like EVP_aes_256_cbc_hmac_sha256()
> and EVP_rc4_hmac_md5()?
> If I understand correctly, these are AEAD ciphers (the EVP_CIPH_FLAG_AEAD_CIPHER
> flag is set), so it should be possible to provide AAD data?
> The following seems to work for AEAD ciphers generally but crashes with the
> ciphers I just mentioned:
> EVP_EncryptUpdate(ctx, NULL, &len, aad, aad_len))
> I call this after key and IV setting and before ciphertext input, in fact
> exactly like described here for GCM AEAD ciphers:
> https://wiki.openssl.org/index.php/EVP_Authenticated_Encryption_and_Decryption#Authenticated_Encryption_using_GCM_mode >
> Am I doing something wrong?
The thing to understand about these ciphers is that they are not intended to be
general purpose at all. They are very much specifically designed to work with
TLS. They do not conform to the general AEAD interface that is available for
GCM, CCM, OCB etc.
Instead they use a specific ctrl: EVP_CTRL_AEAD_TLS1_AAD. This takes as an
argument a pointer to the AAD which must be EVP_AEAD_TLS1_AAD_LEN (13) bytes
long and in a defined format.
> Second question:
> The comments around AES_decrypt() and AES_encrypt() in crypto/aes/aes_core.c
> state: "in and out can overlap".
> Does this only apply to the pure C version of AES, or to any or all assembly
> implementations as well?
As a general rule we allow "in place" encryption but not "partially overlapping"