Using the sp math library I get the smallest flash footprint but the RsaKey structure weighs 1572 bytes (as per sizeof()). I checked the struct and saw that the exponent is defined as mp_int, which becomes an sp_int, which is always an array of 193 32-bit words. That's 772 bytes when e->used is always 1.

struct RsaKey {
    mp_int n, e;
    //...

Is it necessary to have so much space dedicated to the exponent?

Just to add a bit of context, I am working on  a system with 32 kB of RAM, which is already huge (normally we use 3 or 6 kB chips) and with the other requirements of the piece of software I am writing I am down to only 3624 bytes of available RAM.

Whether ECDSA secp256r1 verification is feasible on 16-bit platforms using only configuration (without custom math)?
If so, what is the recommended way to configure the library to bypass ecc_verify_hash_sp and ensure compatibility?

Thank you!

I'm trying to integrate WolfSSL into a project using Keil uVision EDK, but trying to use the packages 5.8.0 or 5.8.2 cause a compilation error because the project is being asked to compile two files that are not present:

• %LocalAppData%\Arm\Packs\wolfSSL\wolfSSL\5.8.2\wolfssl\wolfcrypt\src\port\arm\thumb2-kyber-asm_c.c

• %LocalAppData%\Arm\Packs\wolfSSL\wolfSSL\5.8.2\wolfssl\wolfcrypt\src\ext_kyber.c

The packages were downloaded from http://www.wolfssl.com/files/ide/wolfSS … 5.8.0.pack, and http://www.wolfssl.com/files/ide/wolfSS … 5.8.2.pack.

The package for 5.7.6 had no issues and let me compile without issues, but I would need the 5.8.2 version for some of the fixes to the STM32 Hardware crypto.

Do you know if there is a way to tell uVision to ignore the file (since it is part of a package, and directly part of WolfCrypt:CORE, uVision doesn't really let me remove the file), or is it possible to have a version of the .pack file that doesn't point to these two removed files?

Best regards,
David

I'm working on wolfSSL in an academic setting. This is part of a larger code base that is using wolfSSL + SGX.

Context: My main code base (currently private) was throwing errors on the SGX part when I added code to validate a certificate chain and a signature. For example, `error: unknown type name ‘time_t’`. In order to track down the issue, to see if this is a problem with my code or with wolfSSL, I was trying to create a separate MWE with only this block of code (to run outside SGX, i.e. with normal wolfSSL).

Current problem: This smaller chunk of code is not throwing errors when compiling, but the output is different depending on the wolfSSL version in use:
- With v5.6.6-stable it works as expected (the output is all zeros).
- With v5.8.2-stable, however, the code errors out when trying to load the first certificate.

The code fails in function

wolfSSL_X509_load_certificate_buffer

(L162) with the error ASN_PARSE_E.

I've placed the code in a git repo:
https://github.com/andrade/iamstuck/tre … ain-verify

In addition, the README has the output of the code when run with 5.6.6 (same version as in Ubuntu repositories) and with 5.8.2, which is the latest stable version.

Any idea on what is wrong?

Regards,
Daniel

I have been trying to implement RSA on the Raspberry Pi Pico 2W RP2350 microcontroller with the Dual Cortex-M33 processor. However, I am getting stuck at wc_MakeRsaKey

RsaKey priv;
WC_RNG rng;
int ret = 0;
long e = 65537; // standard value to use for exponent

ret = wc_InitRsaKey(&priv, NULL);
printf("wc_InitRsaKey ret: %d\n", ret);
ret = wc_InitRng(&rng);
printf("wc_InitRng ret: %d\n", ret);
ret = wc_RsaSetRNG(&priv, &rng);
printf("wc_RsaSetRNG ret: %d\n", ret);
// generate 2048 bit long private key
ret = wc_MakeRsaKey(&priv, 2048, e, &rng);
printf("wc_MakeRsaKey ret: %d\n", ret);

I have tried the benchmark tests and have been unable to replicate the results at https://www.wolfssl.com/docs/benchmarks/
The platform that WolfSSL tested with is slightly different:
Raspberry Pi Pico-W
ARM Cortext M0+, 125MHz
When trying to run to run bench_main from the example repository in WolfSSL:
https://github.com/wolfSSL/wolfssl-exam … nch_main.c
The code gets stuck at RSA.

I saw a blog post here related to this issue:
https://www.wolfssl.com/forums/topic125 … stops.html

However, I am unsure if this is the issue and, if so, how to resolve it for my Pico 2W. Any help is appreciated.

Do I need to always call the initializations?

I’m integrating the wolfSSL (v5.7.6) library into an Infineon Aurix (tc3xx) which utilizes a HSM (etas Cycur HSM). I'm trying to offload various crypto functions to the HSM and am running into issues.
Because the HSM is not stateless, each hash operation needs its own session/context, which must be managed per hash object.

Current approach:

On first update, I allocate a context from a memory pool and store it in the devCtx pointer of the wolfSSL hash object.

On finalize, I close the HSM session, free the context, and set devCtx to NULL.

I'm currently not yet at the point where I actually feed the HSM with data, as I am testing if the opening and closing of sessions with the pools themselves work.

Problem:
I’ve observed that wolfSSL sometimes internally copies (clones) the SHA256 context via the wc_Sha256GetHash() function - including my devCtx pointer.
This results in both the original and the copy calling finalize (and freeing the same context), leading to double-free or resource leaks, because there’s no way to distinguish the “real” owner from a clone.

I’ve noticed:

Some device ports (e.g., for ESP, PIC, STM32) and features like WOLFSSL_ASYNC_CRYPT seem to support callback hooks or custom context copy/free handling.

But I haven’t found a generic, portable way to handle context lifecycle events (copy/clone/free) for my own MCU/HSM, or a way to enable these hooks via public configuration.

My questions:

Is there a portable way (not device-specific) to get notified when wolfSSL copies or destroys a hash context, or to customize this process?

If not, is patching the library to add these hooks the only solution, like adding my own wc_Sha256* functions? Another idea would be to omit the sha256.c file and compile in my own instead that handles lifecycle and so on.

Are there plans to expose such lifecycle hooks for generic crypto callback users, or are there any existing workarounds (besides buffering all hash input)?

Why I need this:
My HSM context can’t be blindly copied or freed multiple times.
I need to track ownership, ideally with explicit create/copy/free callbacks, to avoid double-free and allow robust session management - especially if wolfSSL hashes in parallel or clones contexts internally.

Any advice, or pointers to a non-device-specific solution, would be greatly appreciated!

Thanks!

So my question is, if I pass `WOLFSSL_ALT_NAMES` manually like in the example below, will it work correctly, or do I have to enable `opensslall`?

This is configuration I am talking about:

./configure \
    --disable-shared \
    --disable-opensslall \
    --disable-des3 \
    --disable-dh \
    --disable-oldtls \
    --disable-psk \
    --disable-md5 \
    --disable-sha \
    --enable-static \
    --enable-certgen \
    --enable-certext \
    CFLAGS="-arch arm64" \
    CPPFLAGS="-DWOLFSSL_ALT_NAMES" \
    --host=aarch64-apple-darwin

I am using the wolfSSL Cube Configuration file.
I obtain the fastest operations for secp256r1 with WOLF_CONF_MATH 4, ie. with WOLFSSL_SP and WOLFSSL_SP_ARM_CORTEX_M_ASM defined. With this configuration the benchmark fails for the brainpool curve, with  Error Code -234 Key size error.
The fastest configuration combination for brainpool I tested was WOLF_CONF_MATH 5, ie. with WOLFSSL_SP and WOLFSSL_SP_MATH_ALL defined. But brainpool is in this configuration more than 10 times slower, than secp256r1 in the fast configuration with  WOLFSSL_SP and WOLFSSL_SP_ARM_CORTEX_M_ASM defined.

Am I configuring something wrong or is this the expected behavior and brainpool curves do not work with WOLFSSL_SP_ARM_CORTEX_M_ASM?

Cheers,
Jakob

My user_settings.h defines related to RSA are:

WC_RSA_BLINDING
WC_RSA_PSS
USE_WOLFSSL_MEMORY
WOLFSSL_HAVE_SP_RSA
WOLFSSL_KEY_GEN
TARGET_EMBEDDED

If it helps I have also tried NO_MALLOC which causes the RSA initialization to hang indefinitely.

This on a Linux machine.