Updated Xilinx/AMD Versal Benchmarks

There are three build options for crypto operations when using wolfSSL on Xilinx/AMD Ultrascale+ devices. The lightweight wolfSSL library can use a software only implementation, make use of the ARMv8 crypto extensions along with custom ARM assembly, or offload the operation to the CSU. Each has its trade offs. Recently wolfSSL has made improvements to the ARMv8 optimizations for use with AES-GCM operations.

  • Offloading to the CSU (labeled here as the hardened option) free’s up the CPU for other operations and it leverages the hardening available which provides enhancements like additional protections against DPA (differential power analysis)
  • ARMv8 crypto extensions is very performant for smaller block sizes and can be taken through a FIPS OE with use of PAA (Processor Algorithm Acceleration)

The following tables are raw numbers of the throughput collected. Collecting the performance on even larger block sizes would show that Xilinx/AMD hardened crypto accelerators continue on linearly until reaching their maximum. The hardened numbers were collected previously using FreeRTOS, the software and ARMv8 were collected while running on Petalinux with the latest wolfSSL version 5.8.2. A VMK180 Versal board was used.

Algorithm Hardened – MB/s Block Size
AES-256-GCM-enc-no_AAD 0.19188 16
AES-256-GCM-enc-no_AAD 6.324667 528
AES-256-GCM-enc-no_AAD 12.254902 1024
AES-256-GCM-enc-no_AAD 49.01886 4112
AES-256-GCM-enc-no_AAD 89.60888 7696
AES-256-GCM-enc-no_AAD 181.00591 15888
AES-256-GCM-enc-no_AAD 350.444225 32768
AES-256-GCM-enc-no_AAD 633.100698 65535
Algorithm Software – MB/s Block Size
AES-256-GCM-enc-no_AAD 15.0984 16
AES-256-GCM-enc-no_AAD 31.0764 528
AES-256-GCM-enc-no_AAD 31.5839 1024
AES-256-GCM-enc-no_AAD 32.0214 4112
AES-256-GCM-enc-no_AAD 32.0883 7696
AES-256-GCM-enc-no_AAD 32.1052 15888
AES-256-GCM-enc-no_AAD 32.1038 32768
AES-256-GCM-enc-no_AAD 32.1293 65535
Algorithm ARMv8 – MB/s Block Size
AES-256-GCM-enc-no_AAD 120.862503 16
AES-256-GCM-enc-no_AAD 633.607939 528
AES-256-GCM-enc-no_AAD 715.517677 1024
AES-256-GCM-enc-no_AAD 776.28316 4112
AES-256-GCM-enc-no_AAD 783.198307 7696
AES-256-GCM-enc-no_AAD 793.405041 15888
AES-256-GCM-enc-no_AAD 793.122663 32768
AES-256-GCM-enc-no_AAD 797.332681 65535

For RSA operations the following chart shows performance differences using a 4096 bit key for private key operations. SP stands for Single Precision.

If you have questions about any of the above, please contact us at facts@wolfssl.com or call +1 425 245 8247.
Download wolfSSL Now

New Keystores and Secure Elements Added to wolfSSL (5.8.2)

wolfSSL continues to expand its hardware security ecosystem with significant new additions over the past year. Here are the latest keystores and secure elements now supported by our cryptographic library:

New Secure Element Support

TROPIC01 Secure Element
wolfSSL now includes dedicated crypto callback functions for the TROPIC01 secure element, providing seamless hardware-backed cryptographic operations for enhanced security applications.

Enhanced STM32 Hardware Security

STM32MP135F Platform
Complete hardware acceleration suite featuring:

  • STM32CubeIDE integration
  • Hardware Abstraction Layer (HAL) support for SHA-2 and SHA-3
  • AES hardware acceleration
  • Hardware RNG integration
  • ECC cryptographic operations

Additional STM32 Variants

  • STM32H5 – Advanced performance microcontroller with enhanced security features
  • STM32WBA – Wireless connectivity focused platform for IoT security
  • STM32G4 – General purpose microcontroller series with crypto acceleration
  • STM32U575xx – Ultra-low-power microcontroller boards for battery-powered secure devices
  • STM32 Cube Expansion Pack – Enhanced development environment support

Expanded Renesas Security Solutions

Renesas TSIP v1.15
Enhanced support for RX65N and RX72N platforms including:

  • RSA Public Encrypt and Private Decrypt operations
  • AES-CTR mode hardware acceleration
  • Improved cryptographic performance

Renesas SCE Integration
New crypto-only RSA support providing dedicated hardware acceleration without requiring full TLS integration.

Development Board and Platform Support

Raspberry Pi Enhanced Support

  • RP2350 – Latest generation with enhanced RNG optimizations
  • RP2040 – Improved support with performance-optimized random number generation

RISC-V Platform

  • SiFive HiFive Unleashed Board – Complete RISC-V development board support for hardware-accelerated cryptography

Operating System and Bootloader Integration

Zephyr Project RTOS
Full integration with the Zephyr real-time operating system, including:

  • TPM usage examples
  • Hardware security integration
  • Real-time cryptographic operations

U-Boot Bootloader
Secure boot integration supporting:

  • TPM-based measured boot
  • Hardware security module validation
  • Boot integrity verification

Microchip Harmony (MPLABX)
Complete development ecosystem support including:

  • SPI HAL integration
  • Benchmarking tools
  • Development environment optimization

Advanced Infineon Security Features

Infineon TriCore (TC2XX/TC3XX)
Hardware security module support with comprehensive TPM integration using the WOLFTPM_INFINEON_TRICORE macro.
Infineon SLB9672/SLB9673
Advanced TPM modules featuring:

  • Secure firmware update capabilities
  • Enhanced I2C communication
  • Industrial-grade security certification

Infineon Development Tools

  • Modus Toolbox – Integrated development environment
  • CyHal I2C/SPI – Hardware abstraction layer support

Additional TPM Hardware

Nations NS350
New TPM 2.0 module support expanding our certified hardware ecosystem for secure applications.
Memory Mapped I/O (MMIO) TPMs
Direct memory access support for TPM modules, enabling:

  • Faster cryptographic operations
  • Reduced system overhead
  • Simplified hardware integration

Development Environment Enhancements

Espressif IDE Support
Complete integration with Espressif’s development environment for ESP32 and related platforms.
Windows Visual Studio
New project templates and GitHub Actions testing for Windows development environments.

Advanced Security Features

Pre-provisioned Device Identity Keys
Support for manufacturer-provisioned security credentials, enabling:

  • Zero-touch device provisioning
  • Factory-sealed security credentials
  • Simplified device authentication

Secure Firmware Update
Advanced firmware update capabilities for supported TPM modules with cryptographic verification and rollback protection.

Getting Started

These new hardware security features are available in wolfSSL version 5.7.0 and later, with wolfTPM version 3.0.0 and later. To enable support for your specific platform, consult our documentation or contact our technical support team.
The expanded hardware support demonstrates wolfSSL’s commitment to providing comprehensive security solutions across embedded systems, IoT devices, and enterprise applications.

Questions?

If you have questions about any of the above, please contact us at facts@wolfssl.com, call us at +1 425 245 8247, or visit our FAQ page for more information.
Download wolfSSL Now

Every hardware cryptography scheme wolfSSL has ever enabled

At wolfSSL we support hardware cryptography for a wide range of platforms. The benefits of hardware cryptography include reduced code footprint size, improved security, acceleration of cryptographic operations, and utilization of . For example, this allows everything from wolfBoot to TLS cipher suites to enjoy acceleration of cryptographic operations.

Furthermore, we have deep partnerships with industry leaders such as Intel, NXP, and Renesas. We support standard Intel instruction extensions such as AES-NI, AVX, and ADX and BMI2, and have recently published a joint whitepaper on using wolfBoot with 11th Gen Intel Core processors. We also support NXP’s Cryptographic Accelerator and Assurance Module (CAAM), and have leveraged this for hardware acceleration on a number of NXP i.MX series processors. Other examples include Espressif and Analog Devices, to name but a few.

If you’re curious for a list of every hardware cryptography scheme and platform we have enabled, then read on:

  • MAX32665 and MAX32665:
    AES >128, 192, 256 bit
    AESGCM/td> >128, 192, 256 bit
    RSA/td>
    ECC/td> NIST-P256
    SHA2/td> SHA-256

    Reference:

    1. a href=”https://www.wolfssl.com/max32666-and-max32665-hardware-acceleration-added-to-wolfssl/”>https://www.wolfssl.com/max32666-and-max32665-hardware-acceleration-added-to-wolfssl/

Do you have a platform requiring hardware cryptographic support that isn’t on our list? Or are you curious about benchmarking? Reach out to us at facts@wolfssl.com with the details of your platform and we will be glad to help you! Also, check out our wolfSSL and wolfCrypt benchmark page.

If you have questions about any of the above, please contact us at facts@wolfssl.com or call us at +1 425 245 8247.
Download wolfSSL Now

How to use the wolfSSL staticmemory feature

wolfSSL is an embedded cryptographic library that includes a TLS/DTLS implementation. For resource-constrained devices or safety-critical applications, dynamic memory allocation via malloc and free system calls may be unavailable. To address these scenarios, wolfSSL offers the –enable-staticmemory feature. This feature provides a robust and straightforward allocation mechanism as an alternative. It utilizes a pre-allocated buffer, segmenting it into sections that applications can acquire by calling XMALLOC and release back to the memory pool using XFREE.

To activate this feature, compile wolfSSL using ./configure –enable-staticmemory or, if utilizing a user_settings.h file, define WOLFSSL_STATIC_MEMORY. Subsequently, execute make. Following compilation, the application must invoke wc_LoadStaticMemory to designate the buffer for partitioning and utilization, and then transmit the resulting “heap hint” to all XMALLOC and XFREE calls. By default, XMALLOC and XFREE calls will revert to the system’s malloc and free if no “heap hint” is provided. To circumvent all system malloc and free calls, the macro WOLFSSL_NO_MALLOC can be defined. For instance, this can be achieved via ./configure –enable-staticmemory CPPFLAGS=-DWOLFSSL_NO_MALLOC.

An additional option available, introduced in wolfSSL version 5.7.0 and subsequent releases, is the utilization of a globally defined “heap hint.” This global heap hint is established by invoking the setter function void* wolfSSL_SetGlobalHeapHint(void* heap). Consequently, any invocation of XMALLOC or XFREE that receives a NULL pointer as the “heap hint” will default to employing the globally configured “heap hint” pointer.

Setting up the memory sizes to use for each of the sections can be a difficult problem. To help some with a base configuration of the memory sizes there is a relatively new memory “bucket” optimizer tool located in the wolfssl-examples repository. It takes in the logging output of memory allocation calls from an application and provides a suggested static memory configuration based on the results. It’s possible in some cases to get even more optimized with the configuration but this example application gives a very good starting point.

The following is an example output when providing the memory logs of testwolfcrypt to the optimizer:

Building wolfSSL and collecting memory usage logs

$ ./configure --enable-staticmemory CPPFLAGS="-DWOLFSSL_DEBUG_MEMORY -DWOLFSSL_DEBUG_MEMORY_PRINT" -q && make > /dev/null && ./wolfcrypt/test/testwolfcrypt &> testwolfcrypt.log

Running the optimizer application on the resulting memory usage log

$ make
gcc  -o memory_bucket_optimizer memory_bucket_optimizer.c -lwolfssl

$./memory_bucket_optimizer testwolfcrypt.log 
Found 24 unique allocation sizes
Peak heap usage: 60074 bytes (maximum concurrent memory usage)
Allocation Sizes, Frequencies, and Concurrent Usage:
Size    Count   Max Concurrent
----    -----   --------------
4208    1       1
3128    914     19
2112    85      1
1600    13      1
1120    13      1
1040    1       1
1024    4       2
800     37      1
257     65      2
256     9       1
235     7       1
227     5       1
223     5       1
207     5       1
191     5       1
136     5       1
128     8       1
104     5       1
72      5       1
64      6       1
48      5       1
32      2       1
28      1       1
0       0       0
Optimization Summary:
Padding size per bucket: 32 bytes
Maximum unique buckets allowed: 9
Total buckets created: 9
Note: Reached maximum bucket limit (9). Some allocations may use larger buckets.
Note: Allocations with waste < padding size use existing buckets to reduce overhead
Note: Bucket limit helps balance memory efficiency vs. management overhead
Optimized Bucket Sizes and Distribution:
Data Size + Padding = Bucket Size    Dist
----------------------------------------
272     + 32      = 304            2
800     + 32      = 832            1
1024    + 32      = 1056           2
1040    + 32      = 1072           1
1120    + 32      = 1152           1
1600    + 32      = 1632           1
2112    + 32      = 2144           1
3136    + 32      = 3168           19
4208    + 32      = 4240           1
WOLFMEM_BUCKETS and WOLFMEM_DIST Macros:
#define WOLFMEM_BUCKETS 304,832,1056,1072,1152,1632,2144,3168,4240
#define WOLFMEM_DIST 2,1,2,1,1,1,1,19,1
Memory Efficiency Analysis:
Note: Allocations with waste < 32 bytes (padding size) use existing buckets
Size    Count   Concurrent Bucket   Waste   Coverage
----    -----   ---------- ------   -----   --------
4208    1       1          4240    0       ?
3128    914     19         3168    8       ?
2112    85      1          2144    0       ?
1600    13      1          1632    0       ?
1120    13      1          1152    0       ?
1040    1       1          1072    0       ?
1024    4       2          1056    0       ?
800     37      1          832     0       ?
257     65      2          304     15      ?
256     9       1          304     16      ?
235     7       1          304     37      ?
227     5       1          304     45      ?
223     5       1          304     49      ?
207     5       1          304     65      ?
191     5       1          304     81      ?
136     5       1          304     136     ?
128     8       1          304     144     ?
104     5       1          304     168     ?
72      5       1          304     200     ?
64      6       1          304     208     ?
48      5       1          304     224     ?
32      2       1          304     240     ?
28      1       1          304     244     ?
0       0       0          304     272     ?
Efficiency Summary:
Total allocations: 1206
Allocations handled: 1206 (100.0%)
Total memory waste: 16654.00 bytes
Average waste per allocation: 13.81 bytes
Total bucket memory: 73984 bytes
Memory overhead: 1239 bytes
  - Padding per bucket: 32 bytes (included in bucket sizes)
  - Heap structures: 296 bytes
  - Alignment: 15 bytes
Total memory needed: 75223 bytes
Data memory: 3141010 bytes
Buffer Size Recommendations:
============================
Minimum buffer size needed: 75224 bytes
Usage in wolfSSL application:
============================
// Allocate buffer
byte staticBuffer[75224];
// Load static memory
WOLFSSL_HEAP_HINT* heapHint = NULL;
if (wc_LoadStaticMemory_ex(&heapHint, 9, bucket_sizes, bucket_dist,
    staticBuffer, 75224, 0, 0) != 0) {
    // Handle error
}
// Use in wolfSSL context
wolfSSL_CTX_load_static_memory(&method, NULL, staticBuffer,
    75224, 0, 1);

Additional documentation about the staticmemory feature can be found in the wolfSSL manual.

If you have questions about any of the above, please contact us at facts@wolfssl.com or call us at +1 425 245 8247.

Download wolfSSL Now

The Radio Equipment Directive (RED) and Evolving Cybersecurity Requirements

The Radio Equipment Directive (RED) 2014/53/EU establishes the regulatory framework for placing radio equipment on the European market. Its goal is to create a unified market while ensuring essential requirements for safety, electromagnetic compatibility, efficient use of the radio spectrum, and more recently cybersecurity and data protection.

To strengthen protections, the European Commission activated Articles 3(3)(d), (e), and (f), which address cybersecurity, privacy, and fraud prevention for certain categories of connected devices. In addition, Articles 3(3)(i) and 4 focus on ensuring that radio equipment remains compliant and interoperable when software updates or modifications are introduced.

These developments overlap with the Cyber Resilience Act (CRA), which will shift some cybersecurity requirements away from RED. Still, RED remains critical, particularly for compliance related to software updates and radio equipment security.

wolfSSL and RED Compliance

  • Lightweight TLS/crypto for constrained devices
  • FIPS 140-3 validated wolfCrypt for compliance-focused markets
  • Support for modern protocols and algorithms, including Post-Quantum Cryptography
  • Open source allows third party audits

wolfSSL delivers the security foundation that helps manufacturers align with RED today, and adapt to future changes tomorrow.

If your team is navigating RED compliance or preparing for CRA, or have questions about any of the above, please contact us at facts@wolfssl.com or call +1 425 245 8247.

Download wolfSSL Now

Support for STM32U5 DHUK

In wolfCrypt and wolfPKCS11 we added support for using a Derived Hardware Unique Key (DHUK) for AES with the STM32U5.

This feature enables use of a device unique AES key (up to 256-bit) available for encryption/decryption. The key cannot be read from the hardware, which makes it great to wrap other symmetric keys for storage and greatly improves security.

In wolfPKCS11 a nice example was added showing how the DHUK can be used to wrap an AES key and then make use of that wrapped key for encryption and decryption. Both wrapping with AES-ECB and AES-CBC modes are supported.

Check out the wolfPKCS11 Example and wolfCrypt Feature PR.

If you have questions about any of the above, please contact us at facts@wolfssl.com or call us at +1 425 245 8247.

Download wolfSSL Now

New CMS/PKCS#7 decode APIs for SymmetricKeyPackage, OneSymmetricKey, and EncryptedKeyPackage

Recent commits to wolfSSL have enabled support to decode new CMS/PKCS#7 message types.

The CMS message type EncryptedKeyPackage (defined in RFC 6032) can be decoded with the new API .

The CMS message types SymmetricKeyPackage and OneSymmetricKey (defined in RFC 6031) can be decoded with the new APIs

wc_PKCS7_DecodeSymmetricKeyPackageAttribute(),
wc_PKCS7_DecodeSymmetricKeyPackageKey(),
wc_PKCS7_DecodeOneSymmetricKeyAttribute(),
and
wc_PKCS7_DecodeOneSymmetricKeyKey().

If you have questions about any of the above, please contact us at facts@wolfssl.com or call +1 425 245 8247.

Download wolfSSL Now

Relaxing CMS/PKCS#7 decode support requirements

Previous wolfSSL versions required X.963 KDF support and AES keywrap functionality to be enabled in order to build CMS/PKCS#7 decode support.

Recent changes to wolfSSL have allowed CMS/PKCS#7 decode support to be built without either of these requirements.

Previously, if the user desired to have the HAVE_PKCS7 build option defined, then the HAVE_X963_KDF and HAVE_AES_KEYWRAP build options were also required. Now, the HAVE_X963_KDF and HAVE_AES_KEYWRAP build options are optional and wolfSSL can be built with HAVE_PKCS7 enabled and either or neither of these build options enabled.

If you have questions about any of the above, please contact us at facts@wolfssl.com or call us at +1 425 245 8247.

Download wolfSSL Now

wolfCrypt MISRA improvements

Some recent pull requests have been merged to the wolfssl repository to allow wolfcrypt to avoid MISRA warnings for certain MISRA 2023 rules.

For example, MISRA rule 3.1 disallows nested comment leaders (e.g. a “//” sequence within a “/* … */” comment block). These have been removed. Also, MISRA rule 8.2 requires function prototypes to include named parameters, so a few instances of prototypes without named parameters have been resolved.

These are initial steps in bringing wolfssl and wolfcrypt into better compliance with the MISRA coding standards.

If you have questions about any of the above, please contact us at facts@wolfssl.com or call +1 425 245 8247.

Download wolfSSL Now

Utilizing PSRAM for wolfSSL Heap Operations for the Espressif ESP32

wolfSSL blog banner highlighting ESP32 heap memory options with 384?kB RAM and 8?MB PSRAM

The latest updates to the Espressif-specific integration of wolfSSL bring a significant enhancement for developers working on memory-constrained embedded systems: support for using PSRAM (pseudo-static RAM) during wolfSSL heap operations.

This improvement not only unlocks larger memory capacity for cryptographic operations, but also lays the foundation for more stable and scalable TLS communication on ESP32 and other Espressif-based platforms.

Why more stable?

Some of the ESP32 chip types have relatively little RAM. Once a large and complex application is written, there may be little leftover room for TLS exchanges. Heap corruption and / or stack overflows will typically ensue, causing undesired stability problems.

What Changed?

The recent GitHub Pull Request #8987 introduces a set of enhancements that allow dynamic memory allocation routines in wolfSSL to take advantage of the extended PSRAM region (when available). This is especially valuable on platforms such as the ESP32-WROVER, ESP32-C3, and ESP32-S3 which support external PSRAM.

Here’s a breakdown of the key updates:

Custom Allocator Integration

wolfSSL can now check for application-defined memory allocators using wolfSSL_GetAllocators() before falling back to the default FreeRTOS pvPortMalloc() or realloc() calls. This opens up new flexibility.

For instance, add these #define statements to the wolfssl user_settings.h file.

#define XMALLOC_USER
#define XFREE MY_FREE
#define XMALLOC MY_MALLOC

Then implement custom FREE and MALLOC in the application.

void MY_FREE(void *p, void* heap, int type)
{
    free(p);
}

void* MY_MALLOC(size_t sz, void* heap, int type)
{
    return malloc(sz);
}

With this mechanism, if your app defines a heap allocator that maps to PSRAM (e.g., via heap_caps_malloc(…, MALLOC_CAP_SPIRAM)), wolfSSL will use it.

XREALLOC / XMALLOC / XFREE Wrappers Updated

Custom memory macros (XMALLOC, XFREE, XREALLOC) were updated to redirect to the new PSRAM-aware versions in esp_sdk_mem_lib.c. Debug versions were added as well:

#define XMALLOC(s, h, type) \
    wc_pvPortMalloc((s)) // Uses PSRAM-aware allocator

Debug-Friendly Memory Tracing

For developers debugging memory usage, verbose allocation logging was added when either DEBUG_WOLFSSL or DEBUG_WOLFSSL_MALLOC are defined. This makes it easier to catch leaks, misallocations, or fragmentation in systems where memory is limited.

ESP_LOGE("malloc", "Failed Allocating memory of size: %d bytes", size);

Benefits of PSRAM Integration

Embedded systems often face memory limitations, especially when running TLS sessions, parsing certificates, or handling large buffers. By enabling PSRAM usage in wolfSSL:

  • Larger TLS Buffers: Allows larger I/O buffers and longer certificate chains without heap exhaustion.
  • Stronger Security: Enables features like TLS 1.3 with minimal compromise on memory availability.
  • Scalability: Supports more simultaneous connections or sessions on memory-constrained MCUs.
  • Debugging Support: Optional debug builds can now track allocations and reallocation failures with file/line/function info.

How to Enable It

This integration is automatic if you’re using wolfSSL on ESP-IDF and PSRAM is configured in your project.

For full benefit:

Ensure your build enables PSRAM via menuconfig:
Component config – ESP32-specific – Support for external – SPI-connected RAM

Optionally implement custom allocators using heap_caps_malloc() targeting PSRAM:

void* my_malloc(size_t sz) {
    return heap_caps_malloc(sz, MALLOC_CAP_SPIRAM | MALLOC_CAP_8BIT);
}

Register your allocators:

wolfSSL_SetAllocators(my_malloc, my_free, my_realloc);

As a reminder: No more than CONFIG_LWIP_MAX_SOCKETS sockets should be opened.

Example:

#ifndef NO_WOLFSSL_MEMORY
static void *custom_malloc(size_t size) {
    void* this_custom_malloc;
    this_custom_malloc = heap_caps_malloc(size, MALLOC_CAP_SPIRAM | MALLOC_CAP_8BIT);
    return this_custom_malloc;
}

static void* custom_realloc(void* ptr, size_t size) {
    void* this_custom_realloc;
    this_custom_realloc = heap_caps_realloc(ptr, size, MALLOC_CAP_SPIRAM | MALLOC_CAP_8BIT);
    return this_custom_realloc;
}

static void custom_free(void *ptr) {
    heap_caps_free(ptr);
}
#endif

Then in the main app, use wolfSSL_SetAllocators:

#if defined(NO_WOLFSSL_MEMORY)
    ESP_LOGE(TAG, "Cannot use wolfSSL_SetAllocators with NO_WOLFSSL_MEMORY");
#else
    wolfSSL_SetAllocators((wolfSSL_Malloc_cb)custom_malloc,
                          (wolfSSL_Free_cb)custom_free,
                          (wolfSSL_Realloc_cb)custom_realloc);
#endif

    esp_err_t error = heap_caps_register_failed_alloc_callback(heap_caps_alloc_failed_hook);
    if (error == ESP_OK) {
        ESP_LOGE(TAG, "Success: heap_caps_register_failed_alloc_callback");
    }
    else {
        ESP_LOGE(TAG, "FAILED: heap_caps_register_failed_alloc_callback");
    }

Tested Platforms

This change is specifically tailored for the Espressif ESP-IDF platform, including:

  • ESP32-WROVER
  • ESP32-S3
  • ESP32-C3 (with PSRAM)
  • Any module with external SPI RAM

Acknowledgements

We extend our thanks to Fidel for suggesting, contributing sample code, and helping to test this feature. Congratulations on getting 50 concurrent FreeRTOS tasks running on the ESP32, each communicating with wolfSSL Post Quantum algorithms!

Ing. Fidel Alejandro Rodríguez Corbo, Phd
Smart Electronics Research Group
School of Engineering and Science
Tecnologico de Monterrey,
Av. Eugenio Garza Sada 2501 Sur
Col. Tecnológico, C.P. 64849
Monterrey, Nuevo León, México

Final Thoughts

This patch brings wolfSSL one step closer to optimal memory use in constrained environments. By supporting PSRAM, developers can offload cryptographic operations away from limited internal RAM – enhancing both stability and performance.

wolfSSL continues to push forward in embedded TLS innovation, and these improvements make it an even better fit for secure IoT applications on ESP32.

For more information or to contribute, visit wolfSSL GitHub and explore the Espressif-specific README.

If you have questions about any of the above, please contact us at facts@wolfssl.com or call us at +1 425 245 8247.

Download wolfSSL Now

Posts navigation

1 2 3 4 11 12 13