> I started with an AES256 demo I found at https://github.com/saju/misc and > modified the initialisations to use AES128. The test strings that program > uses are quite short - less than 100 characters. If I add a significantly > longer string to those test values Valgrind reports a string of what I > suspect are buffer overruns. Note that I discovered this in my real code and > this is a simple test case that seems to demonstrate the same problem. I also > print the library version that the program is using.
I don't get any valgrind errors, not a single one. But then I had to add -DAES_BLOCK_SIZE=16 at compiler command line, as program in question failed to include <openssl/aes.h>. Well, I don't really want to say "failed to include", because it implies that I'd suggest to do so, when I don't actually mean to. Correct solution in real life would be to query cipher block size with EVP_CIPHER_block_size, as opposite to relying on cipher-specific header. It's just that I see no point in fixing that program. As for alleged buffer overruns in your program. You have to recognize and remember that AES is a block cipher, which means that CBC encrypt output and decrypt input lengths has to be divisible by block size. [Ideally even encrypt input and decrypt output lengths should be divisible, but EVP gives you some help by padding encrypt input.] In other words, is it possible that you allocate buffer based in input string length, which would actually be prone to overrun. Though I again say things I don't want to say, namely implicitly suggest that it's OK to encrypt null-terminated strings with CBC without application controlled padding. Though, for completeness sake one can mention that there are CBC variants suitable for this purpose, namely Cipher Text Stealing modes, but these are not supported by OpenSSL (yet?). ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
