Category: wolfSSL/ wolfCrypt

It may not be as glamorous as the new ESP32 RISC-V chipsets with all the various hardware acceleration capabilities, but the ESP8266 is a well established device which has a large codebase available with an even larger user community.

Due to high customer demand, we’ve enhanced the wolfSSL libraries for the ESP8266. The recent changes have improved both the ESP-IDF CMake and traditional Makefile builds. This new capability allows for specification of the wolfSSL component source code as an alternative to using the setup script to copy everything locally.

For make, set the WOLFSSL_ROOT value in components/wolfssl/component.mk

For cmake, there are more options:

• Set the WOLFSSL_ROOT value in components/wolfssl/CMakeLists.txt
• Set the WOLFSSL_ROOT environment variable.
• Have the components/wolfssl/CMakeLists.txt as a subdirectory in wolfSSL.

When a project is in a subdirectory of wolfSSL, the cmake file will search parent directories, up to the root, looking for wolfSSL.

The ability to specify the wolfSSL component source code ensures consistent versioning across projects and facilitates easy updates via GitHub.

You may have seen our recent announcement regarding wolfCrypt hardware acceleration for the ESP32 series. There’s no such capability on the ESP8266. However, there’s still a noticeable difference between debug and release optimizations, as shown at the end of this blog.

Once the Espressif ESP8266 RTOS SDK is installed, it is easy to get the wolfSSL examples working (see the README for more details):

# Set your path to RTOS SDK, 
# shown here for default from WSL with VisualGDB
WRK_IDF_PATH=/mnt/c/SysGCC/esp8266/rtos-sdk/v3.4
#  or
WRK_IDF_PATH=~/esp/ESP8266_RTOS_SDK

# Setup the environment
. $WRK_IDF_PATH/export.sh

# Optional: install as needed / prompted
# /mnt/c/SysGCC/esp8266/rtos-sdk/v3.4/install.sh

# Fetch wolfssl from GitHub if needed:
cd /workspace
git clone https://github.com/wolfSSL/wolfssl.git

# change directory to wolfssl client example.
cd wolfssl/IDE/Espressif/ESP-IDF/examples/wolfssl_client

# Adjust settings as desired
# Set IP address and wifi SSID name & password
idf.py menuconfig

# Build, flash and monitor
idf.py build flash -p /dev/ttyS70 -b 115200
idf.py monitor -p /dev/ttyS70 -b 74880

Are you interested in using the ESP8266 or ESP32 in your next project? Let us know! We love to hear about how wolfSSL is being used, and can optionally help promote your project on social media, with your approval.

Get Started with wolfSSL

Additional information on getting Started with wolfSSL on the Espressif environment is available on the wolfSSL GitHub repository as well as this YouTube recording:

Benchmark metrics for the ESP8266, compiler optimization for size (-oS):

Chip is ESP8266 (revision v1), Crystal is 26MHz, cpu freq: 160000000 Hz (160MHz)

I (59) boot: ESP-IDF v3.4 2nd stage bootloader
I (59) boot: compile time 13:01:06
I (68) qio_mode: Enabling default flash chip QIO
I (68) boot: SPI Speed      : 40MHz
I (72) boot: SPI Mode       : QIO
I (78) boot: SPI Flash Size : 2MB
I (84) boot: Partition Table:
I (89) boot: ## Label            Usage          Type ST Offset   Length
I (101) boot:  0 nvs              WiFi data        01 02 00009000 00006000
I (112) boot:  1 phy_init         RF data          01 01 0000f000 00001000
I (124) boot:  2 factory          factory app      00 00 00010000 000f0000
I (136) boot: End of partition table
I (142) esp_image: segment 0: paddr=0x00010010 vaddr=0x40210010 size=0x40874 (264308) map
I (227) esp_image: segment 1: paddr=0x0005088c vaddr=0x40250884 size=0x13cd4 ( 81108) map
I (250) esp_image: segment 2: paddr=0x00064568 vaddr=0x3ffe8000 size=0x004d0 (  1232) load
I (251) esp_image: segment 3: paddr=0x00064a40 vaddr=0x40100000 size=0x00080 (   128) load
I (262) esp_image: segment 4: paddr=0x00064ac8 vaddr=0x40100080 size=0x045a8 ( 17832) load
I (279) boot: Loaded app from partition at offset 0x10000
I (299) main: This is ESP8266 chip with 1 CPU cores, WiFi, 
I (301) main: silicon revision 1, 
I (303) main: 2MB external flash

wolfCrypt Benchmark (block bytes 1024, min 1.0 sec each)
RNG                        575 KiB took 1.022 seconds,  562.622 KiB/s Cycles per byte =   1.57
AES-128-CBC-enc            125 KiB took 1.247 seconds,  100.241 KiB/s Cycles per byte =  17.25
AES-128-CBC-dec            250 KiB took 1.089 seconds,  229.568 KiB/s Cycles per byte =  12.82
AES-192-CBC-enc            100 KiB took 1.087 seconds,   91.996 KiB/s Cycles per byte =  42.30
AES-192-CBC-dec            225 KiB took 1.019 seconds,  220.805 KiB/s Cycles per byte =  23.32
AES-256-CBC-enc            100 KiB took 1.189 seconds,   84.104 KiB/s Cycles per byte =  64.92
AES-256-CBC-dec            225 KiB took 1.075 seconds,  209.302 KiB/s Cycles per byte =  33.33
AES-128-GCM-enc             75 KiB took 1.001 seconds,   74.925 KiB/s Cycles per byte = 113.90
AES-128-GCM-dec             75 KiB took 1.001 seconds,   74.925 KiB/s Cycles per byte = 126.15
AES-192-GCM-enc             75 KiB took 1.053 seconds,   71.225 KiB/s Cycles per byte = 139.33
AES-192-GCM-dec             75 KiB took 1.053 seconds,   71.225 KiB/s Cycles per byte = 153.21
AES-256-GCM-enc             75 KiB took 1.137 seconds,   65.963 KiB/s Cycles per byte = 168.58
AES-256-GCM-dec             75 KiB took 1.137 seconds,   65.963 KiB/s Cycles per byte = 183.13
GMAC Default               342 KiB took 1.001 seconds,  341.658 KiB/s Cycles per byte =  43.08
3DES                       200 KiB took 1.115 seconds,  179.372 KiB/s Cycles per byte =  79.45
MD5                       5225 KiB took 1.000 seconds, 5225.000 KiB/s Cycles per byte =   3.22
SHA                       2300 KiB took 1.000 seconds, 2300.000 KiB/s Cycles per byte =   7.76
SHA-224                   1475 KiB took 1.009 seconds, 1461.843 KiB/s Cycles per byte =  12.71
SHA-256                   1475 KiB took 1.008 seconds, 1463.294 KiB/s Cycles per byte =  13.40
SHA-384                    475 KiB took 1.014 seconds,  468.442 KiB/s Cycles per byte =  43.79
SHA-512                    475 KiB took 1.012 seconds,  469.368 KiB/s Cycles per byte =  45.90
SHA-512/224                475 KiB took 1.012 seconds,  469.368 KiB/s Cycles per byte =  47.99
SHA-512/256                475 KiB took 1.013 seconds,  468.904 KiB/s Cycles per byte =  50.12
SHA3-224                  1250 KiB took 1.018 seconds, 1227.898 KiB/s Cycles per byte =  19.77
SHA3-256                  1175 KiB took 1.003 seconds, 1171.486 KiB/s Cycles per byte =  21.96
SHA3-384                   925 KiB took 1.021 seconds,  905.975 KiB/s Cycles per byte =  28.84
SHA3-512                   650 KiB took 1.024 seconds,  634.766 KiB/s Cycles per byte =  42.68
SHAKE128                  1450 KiB took 1.011 seconds, 1434.224 KiB/s Cycles per byte =  19.80
SHAKE256                  1175 KiB took 1.002 seconds, 1172.655 KiB/s Cycles per byte =  25.22
RIPEMD                    4375 KiB took 1.002 seconds, 4366.267 KiB/s Cycles per byte =   7.01
HMAC-MD5                  5175 KiB took 1.002 seconds, 5164.671 KiB/s Cycles per byte =   6.11
HMAC-SHA                  2325 KiB took 1.009 seconds, 2304.262 KiB/s Cycles per byte =  14.05
HMAC-SHA224               1475 KiB took 1.017 seconds, 1450.344 KiB/s Cycles per byte =  22.83
HMAC-SHA256               1475 KiB took 1.017 seconds, 1450.344 KiB/s Cycles per byte =  23.46
HMAC-SHA384                475 KiB took 1.049 seconds,  452.812 KiB/s Cycles per byte =  74.96
HMAC-SHA512                475 KiB took 1.048 seconds,  453.244 KiB/s Cycles per byte =  77.12
PBKDF2                       0 KiB took 1.077 seconds,    0.174 KiB/s Cycles per byte = 201056.28
RSA     1024  key gen         1 ops took 65.685 sec, avg 65685.000 ms, 0.015 ops/sec
RSA     2048  key gen         1 ops took 77.480 sec, avg 77480.000 ms, 0.013 ops/sec
RSA     2048   public        10 ops took 1.035 sec, avg 103.500 ms, 9.662 ops/sec
RSA     2048  private         2 ops took 44.756 sec, avg 22378.000 ms, 0.045 ops/sec
ECC   [      SECP256R1]   256  key gen         2 ops took 1.662 sec, avg 831.000 ms, 1.203 ops/sec
ECDHE [      SECP256R1]   256    agree         2 ops took 1.668 sec, avg 834.000 ms, 1.199 ops/sec
ECDSA [      SECP256R1]   256     sign         2 ops took 1.688 sec, avg 844.000 ms, 1.185 ops/sec
ECDSA [      SECP256R1]   256   verify         2 ops took 3.212 sec, avg 1606.000 ms, 0.623 ops/sec
CURVE  25519  key gen         2 ops took 1.785 sec, avg 892.500 ms, 1.120 ops/sec
CURVE  25519    agree         2 ops took 1.326 sec, avg 663.000 ms, 1.508 ops/sec
ED     25519  key gen        15 ops took 1.009 sec, avg 67.267 ms, 14.866 ops/sec
ED     25519     sign        14 ops took 1.008 sec, avg 72.000 ms, 13.889 ops/sec
ED     25519   verify         6 ops took 1.140 sec, avg 190.000 ms, 5.263 ops/sec
Benchmark complete

Benchmark metrics for the ESP8266, No Compiler Optimization (debug -Og):

Chip is ESP8266 (revision v1), Crystal is 26MHz, cpu freq: 160000000 Hz (160MHz)

I (60) boot: ESP-IDF v3.4 2nd stage bootloader
I (60) boot: compile time 14:00:00
I (69) qio_mode: Enabling default flash chip QIO
I (69) boot: SPI Speed      : 40MHz
I (73) boot: SPI Mode       : QIO
I (79) boot: SPI Flash Size : 2MB
I (85) boot: Partition Table:
I (91) boot: ## Label            Usage          Type ST Offset   Length
I (102) boot:  0 nvs              WiFi data        01 02 00009000 00006000
I (114) boot:  1 phy_init         RF data          01 01 0000f000 00001000
I (125) boot:  2 factory          factory app      00 00 00010000 000f0000
I (137) boot: End of partition table
I (143) esp_image: segment 0: paddr=0x00010010 vaddr=0x40210010 size=0x46e48 (290376) map
I (255) esp_image: segment 1: paddr=0x00056e60 vaddr=0x40256e58 size=0x14560 ( 83296) map
I (284) esp_image: segment 2: paddr=0x0006b3c8 vaddr=0x3ffe8000 size=0x004dc (  1244) load
I (285) esp_image: segment 3: paddr=0x0006b8ac vaddr=0x40100000 size=0x00080 (   128) load
I (296) esp_image: segment 4: paddr=0x0006b934 vaddr=0x40100080 size=0x046a4 ( 18084) load
I (315) boot: Loaded app from partition at offset 0x10000
I (334) main: This is ESP8266 chip with 1 CPU cores, WiFi, 
I (337) main: silicon revision 1, 
I (339) main: 2MB external flash

wolfCrypt Benchmark (block bytes 1024, min 1.0 sec each)
RNG                        375 KiB took 1.019 seconds,  368.008 KiB/s Cycles per byte =   2.74
AES-128-CBC-enc             75 KiB took 1.168 seconds,   64.212 KiB/s Cycles per byte =  27.59
AES-128-CBC-dec            475 KiB took 1.045 seconds,  454.545 KiB/s Cycles per byte =   6.43
AES-192-CBC-enc             75 KiB took 1.272 seconds,   58.962 KiB/s Cycles per byte =  57.19
AES-192-CBC-dec            425 KiB took 1.007 seconds,  422.046 KiB/s Cycles per byte =  12.70
AES-256-CBC-enc             75 KiB took 1.362 seconds,   55.066 KiB/s Cycles per byte =  88.98
AES-256-CBC-dec            400 KiB took 1.053 seconds,  379.867 KiB/s Cycles per byte =  19.31
AES-128-GCM-enc             75 KiB took 1.440 seconds,   52.083 KiB/s Cycles per byte = 121.83
AES-128-GCM-dec             75 KiB took 1.440 seconds,   52.083 KiB/s Cycles per byte = 141.40
AES-192-GCM-enc             50 KiB took 1.026 seconds,   48.733 KiB/s Cycles per byte = 230.32
AES-192-GCM-dec             50 KiB took 1.026 seconds,   48.733 KiB/s Cycles per byte = 249.89
AES-256-GCM-enc             50 KiB took 1.076 seconds,   46.468 KiB/s Cycles per byte = 273.47
AES-256-GCM-dec             50 KiB took 1.076 seconds,   46.468 KiB/s Cycles per byte = 294.31
GMAC Default               247 KiB took 1.003 seconds,  246.261 KiB/s Cycles per byte =  63.60
3DES                       175 KiB took 1.121 seconds,  156.111 KiB/s Cycles per byte =  95.82
MD5                       1100 KiB took 1.008 seconds, 1091.270 KiB/s Cycles per byte =  16.18
SHA                       3900 KiB took 1.000 seconds, 3900.000 KiB/s Cycles per byte =   4.82
SHA-224                    925 KiB took 1.007 seconds,  918.570 KiB/s Cycles per byte =  21.27
SHA-256                    925 KiB took 1.002 seconds,  923.154 KiB/s Cycles per byte =  22.43
SHA-384                    850 KiB took 1.009 seconds,  842.418 KiB/s Cycles per byte =  25.58
SHA-512                    850 KiB took 1.007 seconds,  844.091 KiB/s Cycles per byte =  26.63
SHA-512/224                850 KiB took 1.004 seconds,  846.614 KiB/s Cycles per byte =  27.75
SHA-512/256                850 KiB took 1.008 seconds,  843.254 KiB/s Cycles per byte =  28.90
SHA3-224                   700 KiB took 1.000 seconds,  700.000 KiB/s Cycles per byte =  36.47
SHA3-256                   675 KiB took 1.021 seconds,  661.117 KiB/s Cycles per byte =  39.45
SHA3-384                   525 KiB took 1.035 seconds,  507.246 KiB/s Cycles per byte =  52.72
SHA3-512                   375 KiB took 1.048 seconds,  357.824 KiB/s Cycles per byte =  76.24
SHAKE128                   800 KiB took 1.001 seconds,  799.201 KiB/s Cycles per byte =  37.12
SHAKE256                   675 KiB took 1.031 seconds,  654.704 KiB/s Cycles per byte =  45.49
RIPEMD                    4300 KiB took 1.002 seconds, 4291.417 KiB/s Cycles per byte =   7.35
HMAC-MD5                  1100 KiB took 1.017 seconds, 1081.613 KiB/s Cycles per byte =  29.67
HMAC-SHA                  4100 KiB took 1.004 seconds, 4083.665 KiB/s Cycles per byte =   8.20
HMAC-SHA224                925 KiB took 1.021 seconds,  905.975 KiB/s Cycles per byte =  37.38
HMAC-SHA256                925 KiB took 1.016 seconds,  910.433 KiB/s Cycles per byte =  38.53
HMAC-SHA384                825 KiB took 1.002 seconds,  823.353 KiB/s Cycles per byte =  44.42
HMAC-SHA512                850 KiB took 1.024 seconds,  830.078 KiB/s Cycles per byte =  44.23
PBKDF2                       0 KiB took 1.283 seconds,    0.097 KiB/s Cycles per byte = 311171.78
RSA     1024  key gen         1 ops took 28.932 sec, avg 28932.000 ms, 0.035 ops/sec
RSA     2048  key gen         1 ops took 382.088 sec, avg 382088.000 ms, 0.003 ops/sec
RSA     2048   public        12 ops took 1.130 sec, avg 94.167 ms, 10.619 ops/sec
RSA     2048  private         2 ops took 39.968 sec, avg 19984.000 ms, 0.050 ops/sec
ECC   [      SECP256R1]   256  key gen         2 ops took 1.591 sec, avg 795.500 ms, 1.257 ops/sec
ECDHE [      SECP256R1]   256    agree         2 ops took 1.597 sec, avg 798.500 ms, 1.252 ops/sec
ECDSA [      SECP256R1]   256     sign         2 ops took 1.619 sec, avg 809.500 ms, 1.235 ops/sec
ECDSA [      SECP256R1]   256   verify         2 ops took 3.093 sec, avg 1546.500 ms, 0.647 ops/sec
CURVE  25519  key gen         2 ops took 1.988 sec, avg 994.000 ms, 1.006 ops/sec
CURVE  25519    agree         2 ops took 1.529 sec, avg 764.500 ms, 1.308 ops/sec
ED     25519  key gen        17 ops took 1.038 sec, avg 61.059 ms, 16.378 ops/sec
ED     25519     sign        16 ops took 1.041 sec, avg 65.062 ms, 15.370 ops/sec
ED     25519   verify         6 ops took 1.334 sec, avg 222.333 ms, 4.498 ops/sec
Benchmark complete

Questions?

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 best encryption libraries are now available on the PlatformIO environment!

At wolfSSL, we continue to embrace rapid prototyping environments, including Arduino, Visual Studio, and now PlatformIO for VS Code, among other IDE applications.

There are hundreds of boards supported by PlatformIO on numerous frameworks and platforms.

We are providing two different Official wolfSSL libraries: standard and another specifically for Arduino:

• wolfssl/wolfSSL
• wolfssl/Arduino-wolfSSL

There are also two different versions: the stable release versions (above) and these staging updates, with the latest post-release changes.

• wolfssl-staging/wolfSSL
• wolfssl-staging/Arduino-wolfSSL

The stable release versions will generally follow our standard release cycle. The initial 5.7.0 versions include post stable-release updates needed for the Initial PlatformIO support.

See the PlatformIO documentation for Getting Started with PlatformIO.

For Windows users using pio from command line:

set PATH=%PATH%;C:\Users\%USERNAME%\.platformio\penv\Scripts\
pio --help
pio account show

Our initial release has full support for Espressif ESP32 boards, but other boards should work with just a few modifications to the wolfSSL user_settings.h file. See the example configs:

https://github.com/wolfSSL/wolfssl/tree/master/examples/configs

Here’s an example platformio.ini file for the ESP32:

[env:esp32dev]
platform = espressif32
board = esp32dev
framework = espidf
upload_port = COM82
monitor_port = COM82
monitor_speed = 115200
build_flags = -DWOLFSSL_USER_SETTINGS, -DWOLFSSL_ESP32
monitor_filters = direct
lib_deps = wolfssl/wolfSSL@^5.7.0-rev.3b

See also: Espressif Systems Leverages PlatformIO Labs Next-Gen Technology for its Software Products.

Is your device working on the PlatformIO environment with wolfSSL? Send us a message and let us help you get started: support@wolfSSL.com or open an issue on GitHub.

Get Started with wolfSSL

Additional information on getting Started with wolfSSL on the Espressif environment is available on the wolfSSL GitHub repository as well as this YouTube recording:

There’s also a must-see 2024 Roadmap to review all the exciting new features:

Find out more

If you have any feedback, questions, or require support, please don’t hesitate to reach out to us via facts@wolfSSL.com, call us at +1 425 245 8247, or open an issue on GitHub.

Download wolfSSL Now

PQC support for the Zephyr port was introduced in the last wolfSSL release using liboqs. This involved adding necessary files to the CMakeLists.txt for the Zephyr module. Zephyr is an open-source real-time operating system (RTOS) designed for resource-constrained devices and embedded systems. It is maintained by the Linux Foundation and supported by a vibrant community of developers and contributors.

PR #7026 (https://github.com/wolfSSL/wolfssl/pull/7026) also addressed proper random number generation within liboqs by using the wolfSSL interface. Previously, liboqs random data acquisition relied on various sources, depending on the liboqs build configuration. With the changes, a custom RNG method is provided through the OQS_randombytes_custom_algorithm() interface, enabling liboqs to obtain RNG data from wolfSSL for all generic liboqs uses.

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

Download wolfSSL Now

MicroBlaze, developed by Xilinx, is a soft processor core optimized for Xilinx FPGAs. It offers flexibility and scalability, making it suitable for a wide range of applications, including embedded systems and IoT devices. Integrating wolfSSL’s AES-GCM with MicroBlaze is possible and has been done running on a soft CPU on MicroBlaze. In the latest wolfSSL release this integration saw some additional enhancements. When used on a MicroBlaze, wolfSSL’s AES-GCM enhances the security capabilities of FPGA-based systems, enabling developers to implement secure communication protocols and data encryption mechanisms. There is also the option of setting up wolfSSL so that it makes use of Xilinx’s xilsecure while running on the Microblaze. Increasing the AES-GCM performance significantly.

For more information about using wolfSSL on a MicroBlaze or 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

Did you know wolfSSL has integration of RSA-PSS signatures with Certificate Revocation List (CRL) support?

RSA-PSS: Enhancing Security Layers

RSA-PSS, or Probabilistic Signature Scheme, represents a modern approach to digital signatures. Unlike traditional RSA signatures, RSA-PSS offers improved security properties, making it more resilient against various cryptographic attacks. By adopting RSA-PSS, wolfSSL users benefit from heightened security, enhancing the integrity of cryptographic operations.

Certificate Revocation List (CRL): Managing Certificate Integrity

In the realm of certificate management, CRL plays a pivotal role. It serves as a mechanism for indicating the revocation status of digital certificates. With CRL, systems can promptly identify and reject compromised or revoked certificates, bolstering the overall security posture. Integrating CRL support into wolfSSL empowers users with efficient certificate management capabilities, ensuring the authenticity and integrity of cryptographic transactions.

Empowering wolfSSL with RSA-PSS and CRL Integration

The fusion of RSA-PSS with CRL support within wolfSSL is a logical step when providing cutting-edge security solutions. Now, wolfSSL users can leverage the combined strength of RSA-PSS signatures and CRL management to fortify their cryptographic environments.

To delve deeper into the RSA-PSS with CRL integration in wolfSSL, visit our GitHub repository (https://github.com/wolfSSL/wolfssl/pull/7119) or reach out to facts@wolfSSL.com for assistance.

Thank you for entrusting wolfSSL as your ally in cybersecurity.

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

In the last release of wolfSSL there was some house cleaning done on older RSA implementations. The user RSA layer was removed along with the hooks used for tying in IPP. When those were first introduced we had yet to implement SP (single precision) versions of RSA. Fast forward to today, and there is a faster implementation of RSA in wolfSSL itself. In IPP v0.9 it was able to do 990.09 RSA 2048 bit sign operations per second and in wolfSSL 5.7.0 it was able to run 1,015.23 operations per second. Verify operations took around the same time with both libraries now at 35,714 operations per second on average. These measurements were collected on an older Intel(R) Core(TM) i7-4870HQ CPU. Along with a performant implementation of RSA there are now the crypto callbacks if desiring to plug in custom RSA operations. This being the case the –enable-fastrsa, user RSA, and IPP hooks were dropped to lower maintenance and reduce bundle size.

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

Recently, a notable modification was introduced in wolfSSL, a prominent provider of security solutions. Pull request #7245 (https://github.com/wolfSSL/wolfssl/pull/7245) focuses on optimizing memory management by introducing a function to unload intermediate CA certificates and free up memory. Let’s explore the significance of this code change and its potential impact on enhancing efficiency and resource utilization within cryptographic applications.

Specifically, the code change addresses the need to efficiently handle intermediate Certificate Authority (CA) certificates. These certificates, while essential for establishing trust chains in cryptographic operations, can consume valuable memory resources, particularly in resource-constrained environments.

The essence of the code change lies in the introduction of a dedicated function (wolfSSL_CertManagerUnloadIntermediateCerts()) to unload intermediate CA certificates from memory when they are no longer needed. By using this function, developers can optimize resource utilization, thereby enhancing the overall efficiency and stability of cryptographic operations.

Key Benefits: The introduction of the function to unload intermediate CA certificates brings several notable benefits:

1. Efficient Memory Management: By providing a mechanism to unload intermediate CA certificates from memory, the code change ensures efficient utilization of resources. This is particularly crucial in environments where memory constraints are a concern, such as embedded systems and IoT devices.
2. Prevention of Memory Leaks: Memory leaks can pose significant security and reliability risks in software applications. The new function helps prevent memory leaks by explicitly releasing memory allocated for intermediate CA certificates when they are no longer required, thereby improving the robustness of cryptographic operations.
3. Scalability and Performance: Optimal memory management contributes to improved scalability and performance of cryptographic applications. By freeing up memory resources, the code change enables applications to handle larger workloads more efficiently, leading to enhanced responsiveness and overall performance.

By incorporating the function to unload intermediate CA certificates, developers can optimize resource utilization and mitigate potential security risks associated with memory management issues. This not only enhances the reliability and stability of cryptographic applications but also contributes to the overall security resilience of the systems in which they are deployed.

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

wolfSSL is announcing a long term support (LTS) version of the wolfSSL library. The goal of this product will be to provide users with fully ABI compatible releases of wolfSSL that are secure against all known vulnerabilities. Patches for vulnerabilities will be backported to the LTS branch in an ABI compatible way to guarantee security and stability.

ABI (Application Binary Interface) is a low-level interface that defines how functions and data structures are accessed in machine code. ABI specifies how parameters are passed to functions, how return values are retrieved, and how data structures are arranged in memory. Guaranteeing ABI stability means that compiling a newer version of the library with the same configuration will work with programs linked against an older release.

wolfSSL LTS will provide users with a stable and reliable library that can be kept up to date with no additional headache. Your programs will always be compatible with the latest wolfSSL LTS release and will be safe from discovered vulnerabilities. Separating out a LTS branch will allow us to continue developing and improving wolfSSL without the strict restrictions of ABI backwards compatibility. Users will be able to choose the appropriate version for them based on their individual priorities.

wolfSSL LTS, like all of our libraries, will be offered under a dual-license model. GPL will be available for open source users and a commercial license will be available for customers integrating it in commercial products. Additional limited backporting services will also be available for customers.

If you’re interested in wolfSSL LTS or have questions about any of the above, please reach to us at facts@wolfSSL.com or call us at +1 425 245 8247!

Download wolfSSL Now

Recently, we have seen an uptick in interest in securing communications between different embedded modules within a larger system. The academic community has seen great work in showing that these communications need to be secured; especially in the automotive space.

Are you looking to start securing your internal communications over UART, I2C or SPI? With wolfSSL, no matter how small and constrained your micro-controller, we can help!! You can make trade-offs and set build flags to suit your needs with regards to code size, memory usage and binary footprint size. For example, if you are running a TLS 1.3 client, we have flags to exclude all server-only code and exclude all earlier versions of TLS and SSL.

Some might find the idea of TLS over UART, I2C or SPI to be somewhat strange. Isn’t TLS supposed to be running over a network connection? Actually, with our IO callback system, there is no problem at all. For a great example of how to do it, you can have a look at our STM32 example code. There we show TLS 1.3 over UART both as server and client. Please have a look at https://github.com/wolfSSL/wolfssl/blob/master/IDE/STM32Cube/wolfssl_example.c. You can search there for the ENABLE_TLS_UART macro to better understand how it hooks into our IO callbacks.

Want more details? Want to discuss further how you can secure your data interfaces on your micro-controller? Reach out to facts@wolfssl.com.

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

Version 5.7.0 of wolfSSL is now available! Many new and exciting features were added in this release. Near the top of that list is the addition of our Kyber implementation along with other post quantum algorithm support. This empowers you to future-proof your security measures, ensuring robust protection against evolving threats. In addition to introducing new features, we’ve addressed three vulnerabilities in this release. Two of these fixes target vulnerabilities related to row hammer attacks, while the other addresses a TLS 1.3 server-side issue. We take security seriously, and you can find more information about these fixes on our vulnerability page (https://www.wolfssl.com/docs/security-vulnerabilities/).

A full list of fixes, additions, and optimizations can be found in the ChangeLog, here are some of the highlights!

• Experimental framework for using wolfSSL’s XMSS and LMS implementation. Explore and test advanced cryptographic techniques within the wolfSSL ecosystem. (PR 7161 & PR 7283)
• Experimental wolfSSL Kyber implementation and assembly optimizations, enabled with –enable-experimental –enable-kyber. Proactively prepare for quantum computing threats with Kyber integration and assembly optimizations. (PR 7318)
• The Linux kernel module now supports registration of AES-GCM, AES-XTS, AES-CBC, and AES-CFB with the kernel cryptosystem through the new –enable-linuxkm-lkcapi-register option, enabling automatic use of wolfCrypt implementations by the dm-crypt/luks and ESP subsystems. In particular, wolfCrypt AES-XTS with –enable-aesni is faster than the native kernel implementation.
• BER content streaming support for PKCS7_VerifySignedData and sign/encrypt operations. Handles large data streams more effectively during PKCS7 operations. (PR 6961 & 7184)
• Microchip PIC24 support and example project expands compatibility, facilitating integration with Microchip’s PIC24 microcontrollers. (PR 7151)
• AutoSAR shim layer provides a standardized interface for RNG, SHA256, and AES (PR 7296)
• wolfSSL_CertManagerUnloadIntermediateCerts API to clear intermediate certs added to certificate store (PR 7245)

This is a small subset of the optimizations and enhancements made in the last release are as follows:

• Remove obsolete user-crypto functionality and Intel IPP support (PR 7097)
• Support for RSA-PSS signatures with CRL use (PR 7119)
• Enhancement for AES-GCM use with Xilsecure on Microblaze (PR 7051)
• Improve liboqs integration adding locking and init/cleanup functions (PR 7026)
• Update Arduino example TLS Client/Server and improve support for ESP32 (PR 7304 & 7177)
• Improvements for Espressif use; SHA HW/SW selection and use on ESP32-C2/ESP8684, wolfSSL_NewThread() type, component cmake fix, and update TLS client example for ESP8266 (PR 7081, 7173, 7077, 7148, 7240)

Visit our download page to download the latest release, or clone it from wolfSSL GitHub. If you have questions about any of the above, feel free to email us at facts@wolfSSL.com or call us at +1 425 245 8247.

Download wolfSSL Now