Allocating Aes / Rsa via sizeof() on the heap is not enough?

[dretax]

Version

5.6.3

Description

A silly question I assume, but If I allocate sizeof(Aes) using malloc, and memset It, afterwards I later use wc_AesGcmSetKey, It would result into exceeding the buffer length. Why is that? Allocating 4 times the sizeof() works fine, and address sanitizer finds no issues either.

[anhu]

Hi @dretax ,

I'm not entirely sure why that would happen, but That is not the correct procedure to use. You will need to use the wc_AesInit() API after the call to malloc(). For example:

wc_AesInit(aes_ptr, NULL, INVALID_DEVID);

Warm regards, Anthony

[dretax]

Hi @dretax ,

I'm not entirely sure why that would happen, but That is not the correct procedure to use. You will need to use the wc_AesInit() API after the call to malloc(). For example:

wc_AesInit(aes_ptr, NULL, INVALID_DEVID);

Warm regards, Anthony

I will check this part if i have but I had similar issue on RSA during init. Memory was somehow not sufficient enough.

if (wc_InitRsaKey(_rsaKey, NULL) != 0)

....

[dretax]

I checked it without allocating times 4 of the size, and with the initialization function you proposed, but address sanitization immediately complains. Ofc I left lots of code out of the context, but I'm not doing anything aside of initializing the variables and setting the keys.

[anhu]

Hi @dretax , is your application code including options.h? That would have many defines that would change the size of structs if the same defines are not defined during wolfSSL library build time.

[dretax]

@anhu I'm building wolfssl via vcpkg manager in manifest mode, which I think could be the reason as you said for the change of size.

What I declare in my project it self when including the headers: "USE_WOLFSSL_IO", "HAVE_AESGCM", "WOLFSSL_TLS13", "HAVE_HKDF", "HAVE_FFDHE_4096", "WC_RSA_PSS", "WOLFSSL_DTLS", "WOLFSSL_DTLS13", "WOLFSSL_SEND_HRR_COOKIE", "WOLFSSL_DTLS_CID", "WC_RSA_BLINDING", "NO_MULTIBYTE_PRINT", "WOLFSSL_KEY_GEN", "WOLFSSL_LIB",

With the custom triplet i made: set(VCPKG_CXX_FLAGS "/DWOLFSSL_USER_SETTINGS=yes /DOPENSSL_EXTRA=true /DWOLFSSL_RIPEMD=true /DNO_PSK=true /DHAVE_EXTENDED_MASTER=true /DWOLFSSL_SNIFFER=true /DHAVE_SECURE_RENEGOTIATION=true /DWOLFSSL_AESGCM_STREAM=true /DWOLFSSL_SHA384=true /DWOLFSSL_SHA512=true /DWC_RSA_OAEP_PADDING=true /DHAVE_SUPPORTED_CURVES=true /DHAVE_TLS_EXTENSIONS=true /DHAVE_ECC=true /DECC_SHAMIR=true /DECC_TIMING_RESISTANT=true /DWOLFSSL_SP_X86_64=true /DSP_INT_BITS=4096 /DWC_RSA_BLINDING=true /DWOLFSSL_KEY_GEN=true /DHAVE_AESGCM=true /DUSE_WOLFSSL_IO=true /DWOLFSSL_TLS13=true /DHAVE_AES_CBC=true /DHAVE_FFDHE_4096=true /DMIN_FFDHE_BITS=4096 /DHAVE_HKDF=true /DHAVE_FFDHE_4096=true /DWC_RSA_PSS=true /DWOLFSSL_DTLS=true /DWOLFSSL_DTLS13=true /DWOLFSSL_SEND_HRR_COOKIE=true /DWOLFSSL_DTLS_CID=true /DNO_MULTIBYTE_PRINT=true /DWOLFSSL_LIB=true") set(VCPKG_C_FLAGS "/DWOLFSSL_USER_SETTINGS=yes /DOPENSSL_EXTRA=true /DWOLFSSL_RIPEMD=true /DNO_PSK=true /DHAVE_EXTENDED_MASTER=true /DWOLFSSL_SNIFFER=true /DHAVE_SECURE_RENEGOTIATION=true /DWOLFSSL_AESGCM_STREAM=true /DWOLFSSL_SHA384=true /DWOLFSSL_SHA512=true /DWC_RSA_OAEP_PADDING=true /DHAVE_SUPPORTED_CURVES=true /DHAVE_TLS_EXTENSIONS=true /DHAVE_ECC=true /DECC_SHAMIR=true /DECC_TIMING_RESISTANT=true /DWOLFSSL_SP_X86_64=true /DSP_INT_BITS=4096 /DWC_RSA_BLINDING=true /DWOLFSSL_KEY_GEN=true /DHAVE_AESGCM=true /DUSE_WOLFSSL_IO=true /DWOLFSSL_TLS13=true /DHAVE_AES_CBC=true /DHAVE_FFDHE_4096=true /DMIN_FFDHE_BITS=4096 /DHAVE_HKDF=true /DHAVE_FFDHE_4096=true /DWC_RSA_PSS=true /DWOLFSSL_DTLS=true /DWOLFSSL_DTLS13=true /DWOLFSSL_SEND_HRR_COOKIE=true /DWOLFSSL_DTLS_CID=true /DNO_MULTIBYTE_PRINT=true /DWOLFSSL_LIB=true")

I probably went insane with it

[anhu]

I'm not quite sure I understand. Can you let me know what is manifest mode?

[dgarske]

Hi @dretax ,

The issue you are having is when your application includes the wolfSSL headers and does a sizeof(Aes) it gets a different value than what wolfSSL needs.

I believe you will find a user_settings.h file that contains all the build options. In your application code you need to set the pre-processor macro WOLFSSL_USER_SETTINGS which will cause our settings.h header to include it. See wolfSSL FAQ 1 here: https://www.wolfssl.com/docs/frequently-asked-questions-faq/#How_do_I_manage_the_build_configuration_for_wolfSSL?

For example the struct Aes has build macros like HAVE_AESGCM. If that macro is not set when you include the aes.h header in your application code the sizeof() will not be the same.

Let me know if that helps.

Thanks, David Garske, wolfSSL

[dretax]

Hi @dretax ,

The issue you are having is when your application includes the wolfSSL headers and does a sizeof(Aes) it gets a different value than what wolfSSL needs.

I believe you will find a user_settings.h file that contains all the build options. In your application code you need to set the pre-processor macro WOLFSSL_USER_SETTINGS which will cause our settings.h header to include it. See wolfSSL FAQ 1 here: https://www.wolfssl.com/docs/frequently-asked-questions-faq/#How_do_I_manage_the_build_configuration_for_wolfSSL?

For example the struct Aes has build macros like HAVE_AESGCM. If that macro is not set when you include the aes.h header in your application code the sizeof() will not be the same.

Let me know if that helps.

Thanks, David Garske, wolfSSL

Hey. As you can see above in my comment, I set it on vcpkg triplet. /DWOLFSSL_USER_SETTINGS=yes

But I actually do not have that specific value set in my binding.gyp as a specific macro, but only HAVE_AESGCM. I'll give it a go and let you know.

[anhu]

Hi @dretax ,

So the size mismatch has gone away. That is great news.

Which macros to define depends on your use case and goals. Is there some sort of functionality you need but are not able to use?

Warm regards, Anthony

[dretax]

@anhu Thank you!

[anhu]

Hi @dretax You're very welcome. I'm glad I could help you! Warm regards, Anthony