Hi kjjy7,

If you are using ./configure you do not need to use user_settings.h. The ./configure outputs a build configuration file to wolfssl/options.h. You can use this file as a template for user_settings.h if you are building the sources directly (without ./configure).

If you are building sources directly then you can define WOLFSSL_USER_SETTINGS and add a user_settings.h file to your include path. There is an excellent template for this here: https://github.com/wolfSSL/wolfssl/blob … settings.h

Thanks,
David Garske, wolfSSL

Hi lupusn00b,

The user_settings.h file is only used when `WOLFSSL_USER_SETTINGS` is defined and is usually used when building the wolfSSL/wolfCrypt sources directly. You asked about only having HMAC+SHA256. It looks like yours is disabling HMAC and SHA256. You should not have the NO_HMAC and NO_SHA256 defined. Also there are a bunch of other defines you'll want for disabling other algorithms.

Here is a good tip: When you run ./configure with your desired options it generates a file in `wolfssl/options.h`. You can use this file as a template for your user_settings.h.

Thanks,
David Garske, wolfSSL

Hi Giovanni,

Have you tried adding `-mlongcalls` to your CFLAGS and CXXFLAGS?

See forum post here:
https://www.esp32.com/viewtopic.php?t=1612

Thanks,
David Garske, wolfSSL

Hi leroyk2,

We have a fix pushed for this here:
https://github.com/wolfSSL/wolfssl/pull/1505

Specifically this line:
https://github.com/wolfSSL/wolfssl/pull … d4937R8575

You may find some of the other improvements in that PR useful as well for the STM32 with CubeMX.

Thanks,
David Garske, wolfSSL

Hi Marco,

The return code from the verify callback allows an error to do overridden. By default the verify callback is only issued in the error case, unless you have `WOLFSSL_ALWAYS_VERIFY_CB` defined. You can use the `store->error` variable to determine the error reason (if one exists). A non-zero return code such a 1 or `WOLFSSL_SUCCESS` allows an error to be overridden. A return value of 0 means continue processing the error in the default way (fail).

For everyones reference the verify callback is set using: `wolfSSL_CTX_set_verify(ctx, WOLFSSL_VERIFY_PEER, myVerify);`

Here are some example implementations we use for internal testing of the verify callback:
https://github.com/wolfSSL/wolfssl/blob … st.h#L1361
https://github.com/wolfSSL/wolfssl/blob … st.h#L1404

Thanks,
David Garske, wolfSSL

Hi olle,

We are looking into the DTLS 1.0 report. We see the CLIENT_HELLO retried even though the SERVER_HELLO is received. We believe this causes the DTLS sever to drop the connection since the second CLIENT_HELLO does not include the same packet information as the first request (its missing TLS extensions). We believe this may be a bug with our DTLS 1.0 code and we hope to have a fix available shortly. Thanks for your details report and we will provide you a followup soon.

Thanks,
David Garske, wolfSSL

Hi jebrando,

To resolve this error you have two options:

1. Enable the hardening options `./configure --enable-harden`
2. Disable the hardening support using `./configure CFLAGS="-DWC_NO_HARDEN`

Thanks,
David Garske, wolfSSL

Hi Telina,

AES CBC mode requires the input to be block aligned. Generally the caller will need to add some type of padding to make sure its 16 byte aligned. It would be okay to just pad with zeros. Some people will pad with the pad count value.

AES CTR mode has a feature where the leftover bytes remain in the `Aes` object and are used on the next call.

You do bring up a good point about the wc_AesCbcEncrypt not checking for block size, however the wc_AesCbcDecrypt does. I'll bring this up with the team this week and let you know the reason for this or get a fix for it.

Thanks,
David Garske, wolfSSL

Hi lalonde,

For the RSA using our signature wrapper `wc_SignatureGenerate` the type `WC_SIGNATURE_TYPE_RSA_W_ENC` adds ASN1 DER encoding which includes the OID around the signature. Both `WC_SIGNATURE_TYPE_RSA` and `WC_SIGNATURE_TYPE_RSA_W_ENC` using PKCS v1.5.

Thanks,
David Garske, wolfSSL

Hi swessidorsaf,

Have you downloaded the latest v3.12.2 release we just posted?
https://github.com/wolfSSL/wolfssl/rele … 2.2-stable

If you are getting a "make check" error can you provide the ./configure string you are using the the platform/OS?

Thanks,
David Garske, wolfSSL

Hi cxdinter,

RSA can encrypt up to the key size (2048 bits is 256 bytes), but it is not something you would normally use to encrypt larger amounts of data because of performance. Typically a key is secretly exchanged using DHE or ECDHE and that key is used as an encryption key for AES, 3DES or ChaCha20. This is what TLS handles automatically. Can you provide some more background to help us understand the situation?

The RSA functions are wc_RsaPublicEncrypt and wc_RsaPrivateDecrypt.
The ECC key agreement is wc_ecc_shared_secret.
The AES encrypt decrypt functions depend on the mode. AES CBC for example is: wc_AesCbcEncrypt and wc_AesCbcDecrypt.

If you are looking for something more lightweight to securely exchange messages you could look at our ECC encrypt example here:
https://github.com/wolfSSL/wolfssl-exam … aster/btle

Thanks,
David Garske, wolfSSL

Hi Ravi,

Thanks for the report. I was able to reproduce a build error with `./configure --disable-ecc -enable-tls13 && make`, so I've issued a PR for it here:
https://github.com/wolfSSL/wolfssl/pull/1187
https://github.com/wolfSSL/wolfssl/pull … 639fbL5059

Marking this forum case as solved.

Thanks,
David Garske, wolfSSL