Month: January 2025

wolfBoot release: v.2.4.0

We are excited to announce the release of wolfBoot 2.4.0, the latest version of our universal secure bootloader. This update brings enhanced platform support, new features, and performance improvements to keep offering the best secure boot solution for all embedded systems.

Integration with wolfHSM and Improved delta updates

A major highlight of this release is the integration with wolfHSM, enabling secure key management through an externally-managed HSM. This integration allows for the transparent management and revocation of the stored public key, as well as support for post-quantum algorithms (ML-DSA).

Delta update detection mechanism has been improved and is now more reliable, with the addition of extra procedures for identifying base image versions.

New hardware targets and platform enhancements

wolfBoot 2.4.0 adds support for the NXP Layerscape LS1028A platform, extending compatibility with high-performance devices.

Support for existing platforms, including ARMv7-M/ARMv8-M, x86-FSP and Xilinx UltraScale+, has been updated with enhanced ARMASM integration, and improved QSPI DMA for efficient memory interaction. Support for Intel TigerLake has improved, with the addition of GDT table support.

New assembly optimizations introduced in latest wolfCrypt have introduced a significant improvement in boot time performance across all ARM family, from Cortex-M devices such as STM32 microcontroller up to the most powerful microprocessors supported.

Bug fixes and updated modules

Key fixes address potential issues in flash write-once mode. Moreover, the core modules have been updated to the latest versions, including wolfSSL 5.7.6 and wolfTPM 3.8.0.

wolfBoot security is powered by wolfCrypt. This means that the secure boot process can be certified to meet FIPS 140-3 requirements and DO-178C safety regulations.

Looking Ahead: Exciting Roadmap for 2025

This year, we’re setting our sights on expanding wolfBoot’s capabilities even further. Planned features include support for running wolfBoot as a supervisor in TrustZone-A, platform support for i.MX-8, and integration with the STM32 MP1 series. Stay tuned for these and more as we continue to innovate and enhance secure boot for all embedded systems.

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 JNI/JSSE 1.15.0 Now Available

wolfSSL JNI/JSSE 1.15.0 is now available for download! This release contains a number of bug fixes and changes to the JNI and JSSE layers.

wolfSSL JNI/JSSE allows for easy use of the native wolfSSL SSL/TLS library from Java. The thin JNI wrapper can be used for direct JNI calls into native wolfSSL, or the JSSE provider (wolfJSSE) can be registered as a Java Security provider for seamless integration underneath the Java Security API. wolfSSL JNI/JSSE provides TLS 1.3 support and can also support running on top of the wolfCrypt FIPS 140-3 validated cryptography module.

Changes in this release are summarized below, but please see ChangeLog.md for a full list.

JSSE System/Security Property Support:

  • wolfssljni.debug – a new System property that enables JNI-level debug logging. This will add debug logs for the lower-level “com.wolfssl.*” classes that are part of the thin wolfSSL JNI wrapper. This is helpful for those users who are using the thin wolfSS JNI wrapper, or for JSSE-level users who need additional low-level debug logging support.

JSSE Changes:

  • Close the underlying Socket when SSLSocket startHandshake() fails before an exception is thrown and returned to the caller.
  • Fix a potential NullPointerException in SSLSocket Input/OutputStream that could happen in a threaded environment with some threads blocked in select()/poll().
  • Add support for SSLSession.getRequestedServerNames() to return the client’s SNI (Server Name Indication) request on the server side.
  • Add checks for legacy DHE keys for cipher suites using keys less than 1024 bits.
  • Optimize Java byte array creation in SSLEngine objects when receiving app data. This has a positive impact on performance by reducing garbage collector pressure.
  • Add the ability for SSLSocket.close() to interrupt read()/write() operations waiting in select()/poll(). This can speed up the return of threads blocked in read or write operations when the socket is closed, instead of waiting for the socket timeout to occur.

JNI Changes:

  • Always call wolfSSL_get1_session() inside WolfSSLSession.getSession() for more consistent native memory handling and cleanup.
  • Call wc_RunAllCast_fips() with wolfCrypt FIPS builds if available. This will run all FIPS Conditional Algorithm Self Tests (CAST) up front when the wolfJSSE provider is registered.
  • Add the ability to pass CFLAGS to java.sh (ie: CFLAGS=”-DTEST_DEFINE” ./java.sh)
  • Remove incorrect ATOMIC_USER preprocessor gate around native wolfSSL_GetSide() inside JNI glue code.

Example Changes:

  • Updates the example Android Studio project, defining WOLFSSL_CERT_REQ and WOLFSSL_CUSTOM_CONFIG. These defines are either not needed, or automatically set when building native wolfSSL on a Linux/Unix platform with “./configure –enable-jni”.

Testing Changes:

  • Add GitHub Actions PRB test for Maven (Linux, macOS) builds
  • Add JUnit tests for SSLSession state at various points throughout the handshake
  • Add GitHub Actions PRB test for native wolfSSL with NO_SESSION_CACHE_REF defined
  • Add GitHub Actions PRB test for WOLFJNI_USE_IO_SELECT

wolfSSL JNI/JSSE 1.15.0 can be downloaded from the wolfSSL download page, and an updated version of the wolfSSL JNI/JSSE User Manual can be found here. For any questions, or to get help using wolfSSL products in your projects, contact us at support@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

wolfCrypt JNI/JCE 1.8.0 Now Available

wolfCrypt JNI/JCE 1.8.0 is now available for download! This release contains a number of bug fixes, changes and new features to help better support usage from applications and 3rd party frameworks that consume wolfJCE internally.

wolfCrypt JNI/JCE allows for easy use of the native wolfCrypt cryptography library from Java. The thin JNI wrapper can be used for direct JNI calls into native wolfCrypt, or the JCE provider (wolfJCE) can be registered as a Java Security provider for seamless integration underneath the Java Cryptography API. wolfCrypt JNI/JCE can also support running on top of the wolfCrypt FIPS 140-3 validated cryptography module.

Changes in this release are summarized below, but please see ChangeLog.md for a full list.

New JCE Functionality:

  • Support for two new Java Security properties designed for use in edge cases where wolfJCE is being used with wolfCrypt FIPS 140-2/3 and the wolfJCE WKS KeyStore is replacing JKS and/or PKCS12 type KeyStore usage from applications for more complete FIPS compliance. Setting these properties to “true” will result in wolfJCE fake registering support for JKS and/or PKCS12 KeyStore support, but will automatically map it down to WKS KeyStore support internally. This can be helpful if using wolfJCE underneath Java code that hard-codes JKS/PKCS12 KeyStore types which cannot be changed, but the actual KeyStore files on disk can be updated to WKS type.
    • wolfjce.mapJKStoWKS
    • wolfjce.mapPKCS12toWKS

JNI and JCE Changes:

  • FIPS Conditional Algorithm Self Tests (CASTs) are now run once up front if wolfJCE is used with wolfCrypt FIPS 140-3, to prevent threaded app errors.

Example Changes:

  • Updated Android Studio example project CMakeLists.txt, defining WOLFSSL_CUSTOM_CONFIG
  • Addition of a JCE cryptography benchmark app (examples/provider/CryptoBenchmark.java). Basic AES-CBC/GCM benchmarks are in place now, but will be expanded to other algorithms in the near future.

Testing Changes:

  • Addition of GitHub Action testing for Maven (pom.xml) builds on macOS and Linux

wolfCrypt JNI/JCE 1.8.0 can be downloaded from the wolfSSL download page, and an updated version of the wolfCrypt JNI/JCE User Manual can be found here. For any questions, or to get help using wolfSSL products in your projects, contact us at support@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

TLS vs. SSH: When To Use Which

TLS and SSH are both widely used protocols used for creating secure connections between two systems over a secure network. But, they are designed for different use cases, so today we are going to take a quick dive into when you should use which.

About TLS

TLS (Transport Layer Security) is what is most commonly used to secure connections to the web, it is the successor to SSL (Secure Sockets Layer) to which wolfSSL gets part of its name. Today, almost all websites use TLS and most web browsers expect a website to use TLS when connecting. It has other use cases, such as email and VNC.

In general, TLS is designed so that a client can authenticate that the intended web server is where the data transfer is happening, and encrypt the data in transit.

About SSH

SSH (Secure SHell) is likely well known if you have used a Linux or Unix-based system before. It is typically used to remotely log into a server and execute commands on that server, as well as transfer files. It is ideal for remote shell or desktop access to machines over an unsecured network.

In addition to our namesake product, wolfSSL, we have a product called wolfSSH, which can provide lightweight SSH client and server support for embedded platforms.

Key Differences

Authentication

SSH allows for many different authentication methods, from basic passwords to keys and certificates. TLS typically relies on a trusted CA (Certificate Authority) for the authentication. Both TLS and SSH support OCSP for certificate revocation status.

Feature Set

SSH not only handles the basic authentication and encryption, but provides the next layer of features, such as shell access, file transfer and port forwarding. TLS is typically a secure wrapper around regular plain protocols.

Another feature SSH provides is the concept of channels. This allows multiplexing of multiple services over one SHH connection. For example, a single connection can have a shell, file transfer and multiple ports forwarded simultaneously.

Performance

TLS, particularly version 1.3, has a very low number of round trips required to handshake between the client and server. Whereas the handshake for SSH is a lot more involved, this can make a new connection a lot more expensive on a high-latency network.

Once the connection is established, the performance of each should be relatively similar, depending on the encryption algorithms used.

Ease Of Use

TLS is designed to be relatively easy to use, in particular, there is a low barrier to entry for the client user. SSH can be more difficult to configure and typically has more steps for the end user due to the mutual authentication.

Summary

Both TLS and SSH are essential parts of securing traffic over untrusted networks. TLS is very useful to wrap existing protocols with a layer of security, whereas SSH is ideal for remote command access to a system and network tunnels.

If you wish to learn more or have questions about any of the above, please contact us at facts@wolfSSL.com or +1 425 245 8247.

Download wolfSSL Now

wolfSSL on STM32 MPUs

STMicroelectronics recently released a new range of ARM based MPUs. These are industrial grade ARM microprocessors that provide excellent performance as well as many useful features. ST have released OpenSTLinux to run on these chips, but they have also made a version of their bare-metal HAL API which works with these chips.

The wolfSSL team has recently ported wolfSSL to bare metal for the STM32MP135F in this range. This chip has a single-core 1GHz ARM Cortex-A7 which has hardware crypto acceleration features. There have been multiple parts to this work, which I will walk through in this post.

HAL porting

The previous AES, HASH and PKA HAL acceleration for STM32 MCUs has been ported to work with the STM32MP13 HAL. Every hardware acceleration feature we have previously supported for STM32 MCUs works with this MPU.

During testing, we clocked the MPU at 650MHz, which is the default high clock speed for bare-metal. At this speed we can get 12MB/sec AES-CBC, 9MB/sec AES-GCM and 90MB/sec SHA256. This is with the core clocked at only 65% of its maximum speed.

Extra hash support

We didn’t just stop there: we also added HAL acceleration for additional SHA types. With this MPU, we can now accelerate SHA-384, SHA-512 and SHA3 types. All also achieving around 85-90MB/sec. This is a 10-30x improvement over what you would typically see when running software-based algorithms for these types on the same hardware.

All the work we did to add these hash types should be easily portable to ST MCUs that support those types in the HAL. You can email us at support@wolfSSL.com if you wish for us to assist you with this porting work.

wolfSSL Example

Setting up and running the MPU in bare-metal mode can be a little bit tricky, so on top of all of this, we created a documented example so that you can create an echo client. This example is designed to be used with the STM32MP135F-DK development board. It uses FreeRTOS and LwIP, so it can be extended to do other things.

The example is available on our wolfssl-examples-stm32 GitHub repository.

There is also a README available in the main wolfSSL source tree, which can guide you through using wolfCrypt with the STM32MP135F.

What about Linux?

For those who want to use OpenSTLinux, wolfSSL “just works”. Using ST’s cross-compile toolchain, you can compile wolfSSL just like you would for any other Linux installation. On Linux, this is the wolfCrypt benchmark results:

------------------------------------------------------------------------------
 wolfSSL version 5.7.4
------------------------------------------------------------------------------
Math:   Multi-Precision: Wolf(SP) word-size=32 bits=4096 sp_int.c
        Single Precision: ecc 256 384 rsa/dh 2048 3072 4096 asm sp_cortexm.c
wolfCrypt Benchmark (block bytes 1048576, min 1.0 sec each)
RNG                         10 MiB took 1.049 seconds,    9.537 MiB/s
AES-128-CBC-enc             20 MiB took 1.003 seconds,   19.931 MiB/s
AES-128-CBC-dec             20 MiB took 1.075 seconds,   18.597 MiB/s
AES-192-CBC-enc             20 MiB took 1.198 seconds,   16.697 MiB/s
AES-192-CBC-dec             20 MiB took 1.254 seconds,   15.947 MiB/s
AES-256-CBC-enc             15 MiB took 1.063 seconds,   14.105 MiB/s
AES-256-CBC-dec             15 MiB took 1.076 seconds,   13.943 MiB/s
AES-128-GCM-enc             10 MiB took 1.044 seconds,    9.577 MiB/s
AES-128-GCM-dec             10 MiB took 1.018 seconds,    9.822 MiB/s
AES-192-GCM-enc             10 MiB took 1.130 seconds,    8.846 MiB/s
AES-192-GCM-dec             10 MiB took 1.128 seconds,    8.867 MiB/s
AES-256-GCM-enc             10 MiB took 1.191 seconds,    8.393 MiB/s
AES-256-GCM-dec             10 MiB took 1.204 seconds,    8.307 MiB/s
GMAC Table 4-bit            20 MiB took 1.014 seconds,   19.716 MiB/s
CHACHA                      35 MiB took 1.102 seconds,   31.750 MiB/s
CHA-POLY                    30 MiB took 1.173 seconds,   25.586 MiB/s
POLY1305                   120 MiB took 1.027 seconds,  116.896 MiB/s
SHA                         45 MiB took 1.029 seconds,   43.727 MiB/s
SHA-256                     25 MiB took 1.042 seconds,   23.988 MiB/s
HMAC-SHA                    45 MiB took 1.075 seconds,   41.845 MiB/s
HMAC-SHA256                 25 MiB took 1.029 seconds,   24.291 MiB/s
RSA     2048   public      1400 ops took 1.043 sec, avg 0.745 ms, 1342.619 ops/sec
RSA     2048  private       100 ops took 2.532 sec, avg 25.324 ms, 39.488 ops/sec
DH      2048  key gen        86 ops took 1.007 sec, avg 11.707 ms, 85.419 ops/sec
DH      2048    agree       100 ops took 1.194 sec, avg 11.939 ms, 83.763 ops/sec
ECC   [      SECP256R1]   256  key gen      1500 ops took 1.023 sec, avg 0.682 ms, 1466.898 ops/sec
ECDHE [      SECP256R1]   256    agree       700 ops took 1.037 sec, avg 1.482 ms, 674.714 ops/sec
ECDSA [      SECP256R1]   256     sign      1200 ops took 1.109 sec, avg 0.924 ms, 1081.961 ops/sec
ECDSA [      SECP256R1]   256   verify       700 ops took 1.146 sec, avg 1.638 ms, 610.589 ops/sec

Details on this can also be found in the wolfSSL STM32MP13 README.

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

Download wolfSSL Now

wolfBoot Support for NXP QorIQ Platforms

wolfBoot supports a wide range of NXP QorlQ platforms. In this post, we will highlight supported platforms, key features, and how wolfBoot ensures security and reliability for PowerPC-based embedded systems.

Why wolfBoot for NXP QorIQ?

wolfBoot is a highly suitable secure boot solution for modern embedded systems. wolfBoot is a U-Boot replacement to improve security. wolfBoot supports features like TPM, encrypted updates, external flash partitions, differential updates, and side channel hardening (armored mode). Production support, commercial grade product, safety critical certified DO178 and FIPS 140-3. Its lightweight design, independence from specific platforms, and ease of integration make it a one-stop solution for developers aiming to improve firmware security.

Key advantages:

  • Efficient and Lightweight: Perfect for resource-constrained environments.
  • Broad Compatibility: Supports PowerPC and Arm-based platforms.
  • Flexible Integration: Simplifies secure firmware updates and key management.

Supported NXP QorIQ PPC Platforms

LS1028A

  • Overview: ARMv8-A architecture with dual Cortex-A72 cores for industrial and networking applications.
  • Features: Integrated TSN (Time-Sensitive Networking), high-speed I/O, and robust peripheral support.
  • Tested Environment: LS1028ARDB Reference Board.

T1024

  • Overview: Dual-core 64-bit PowerPC processor based on the e5500 core, designed for embedded control and communication.
  • Features: Virtualization, encryption acceleration, and advanced networking capabilities.
  • Applications: Secure gateways, industrial automation, and telecom systems.
  • Tested Environment: T1024RDB with NOR flash using IFC.

T2080

  • Overview: High-performance quad-core 64-bit processor using the e6500 core with AltiVec technology for vector processing.
  • Features: Exceptional performance for data-intensive workloads and advanced signal processing.
  • Tested Environment: NAII 68PPC2 hardware.

P1021

  • Overview: A dual-core PPC e500v2 processor.
  • Features: Optimized for secure boot from NAND flash via eLBC (Enhanced Local Bus Controller).
  • Boot Details: Supports first-stage boot loader and execution of wolfBoot for secure firmware validation and application loading.
  • Applications: Ideal for industrial controllers and embedded systems requiring high reliability.
  • Tested Environment: P1021RDB with NAND boot source using eLBC

How wolfBoot Secures NXP QorIQ Systems

wolfBoot ensures safe and trusted execution of firmware with:

  • Secure Boot: Prevents unauthorized firmware from running.
  • Signed Updates: Employs ECC/RSA cryptography for firmware authenticity.
  • Customizable Configurations: Provides example setups for easier implementation across platforms.

Conclusion

Whether you’re working on NXP QorIQ PowerPC platforms or other architectures, wolfBoot is designed to deliver the best security and support. Its compatibility with wide ranges of different processors makes it essential for secure embedded systems development.

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

Download wolfSSL Now

wolfTPM Zephyr Support Coming Soon

wolfSSL is pleased to announce its upcoming wolfTPM support with Zephyr RTOS. Zephyr is an open-source, real-time operating system targeted for resource-constrained devices, which makes it a perfect match for wolfTPM’s lightweight and efficient TPM 2.0 library.

This will introduce hardware-based cryptographic security to IoT and embedded systems. Extending wolfSSL’s existing support for Zephyr supported applications like wolfSSL and wolfSSH.

Stay tuned for future updates about wolfTPM Zephyr support. If you have any further questions about any of the above, please contact us at facts@wolfSSL.com or +1 425 245 8247.

Download wolfSSL Now

Coming Soon: FrodoKEM in wolfCrypt

“Hey wolfSSL, care to show us Europeans some post-quantum love?”

Of course! Here at wolfSSL we were founded in the USA and most of our team is American. Naturally, we have been following NIST (National Institute of Standards and Technology) standards. That said, we love and cherish our European customers and community as well.

Cryptography and communications protocols are international in nature and interoperability requirements span across several borders and oceans. This means that we need to not only look at our own standards bodies but those of other countries as well. Examples of this include our support for the ShangMi ciphers as well as support for the Brainpool ECC (Elliptical Curve Cryptography) curves.

It has been duly noted by wolfSSL that the German BSI (Bundesamt für Sicherheit in der Informationstechnik) and other international organizations are also pushing for industry support and standardization of FrodoKEM. For our customers that are participating in German and other European markets, you can take a sigh of relief and relax. We will soon be starting work on our own implementation of FrodoKEM.

Please do reach out to us letting us know of your interest in FrodoKEM or any other new algorithms that you would like to see implemented in wolfCrypt. Your voice matters as it sets our priorities and can accelerate what we do next!

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

Download wolfSSL Now

Live Webinar: New and Updated: Getting Started with wolfSSH

Start 2025 with insights into the latest in SSH technology! Join us on January 23rd at 10 AM PT for an exclusive webinar, “New and Updated: Getting Started with wolfSSH.” Presented by Jacob Barthelmeh, Senior Software Engineer at wolfSSL, this session will cover the essential topics to help you harness the full potential of wolfSSH.

Register today: New and Updated: Getting Started with wolfSSH
Date: January 23rd | 10 AM PT

This webinar will provide everything you need to know to get started with wolfSSH. Attendees will gain insights into the architectural design to real-world applications, along with tips on building, debugging, and configuration.

Sneak Peek of the Webinar (subject to change):

  • SSH Protocol Overview
  • Supported Algorithms and Hardware Acceleration
  • Building wolfSSH on Various Platforms
  • Key Examples and Real-World Applications
  • Debugging and Troubleshooting Techniques

Don’t miss this opportunity to deepen your understanding of wolfSSH and get answers to your questions directly from a wolfSSL expert! Register now to secure your spot!

As always our webinar will include Q&A throughout. If you have questions about any of the above, please contact us at facts@wolfssl.com or +1 425 245 8247.

Download wolfSSL Now

A slice of security for the Raspberry Pi Pico

Pretty much everyone knows what a Raspberry Pi board is, a very budget-friendly ARM board which runs Linux. What you might not know is that Raspberry Pi also created a very small, cheap, embedded ARM microcontroller range and development board as well. The board is known as the Raspberry Pi Pico and the chip is the RP2040.

The RP2040 is a $1 dual-core ARM Cortex-M0+ microcontroller with lots of features and a very well documented SDK. It was followed-up recently with the RP2350, which, for a similar price, gets you a dual-core ARM Cortex-M33 / RISC-V microcontroller. The RP2350 can be found on the Pi Pico 2 boards.

wolfSSL support

wolfSSL has had basic support for RP2040 for a little while, but with wolfSSL 5.7.6, we have provided improvements to the support. In addition, we have added support for the RP2350.

For both microcontrollers, we have enhanced the performance for RNG. We have integrated support for the PRNG in the Pico SDK for the RP2040 and the TRNG in the RP2350. Both provide performance improvements.

With the RP2350, we have also added support for the RISC-V mode for the cores.

Benchmark

What about the numbers? Well, with a RP2350 in ARM mode, clocked at the default 150MHz, these are the numbers you can expect to see from the wolfCrypt Benchmark:

wolfCrypt Benchmark (block bytes 1024, min 1.0 sec each)
RNG                          3 MiB took 1.001 seconds,    2.855 MiB/s
AES-128-CBC-enc              3 MiB took 1.004 seconds,    2.529 MiB/s
AES-128-CBC-dec              3 MiB took 1.000 seconds,    2.588 MiB/s
AES-192-CBC-enc              2 MiB took 1.007 seconds,    2.157 MiB/s
AES-192-CBC-dec              2 MiB took 1.005 seconds,    2.234 MiB/s
AES-256-CBC-enc              2 MiB took 1.009 seconds,    1.888 MiB/s
AES-256-CBC-dec              2 MiB took 1.003 seconds,    1.898 MiB/s
AES-128-GCM-enc            900 KiB took 1.003 seconds,  897.418 KiB/s
AES-128-GCM-dec            925 KiB took 1.015 seconds,  911.157 KiB/s
AES-192-GCM-enc            850 KiB took 1.006 seconds,  844.758 KiB/s
AES-192-GCM-dec            875 KiB took 1.021 seconds,  856.974 KiB/s
AES-256-GCM-enc            825 KiB took 1.029 seconds,  802.085 KiB/s
AES-256-GCM-dec            825 KiB took 1.015 seconds,  812.705 KiB/s
AES-128-GCM-enc-no_AAD    1000 KiB took 1.017 seconds,  983.142 KiB/s
AES-128-GCM-dec-no_AAD    1000 KiB took 1.004 seconds,  995.881 KiB/s
AES-192-GCM-enc-no_AAD     925 KiB took 1.004 seconds,  921.384 KiB/s
AES-192-GCM-dec-no_AAD     950 KiB took 1.018 seconds,  933.496 KiB/s
AES-256-GCM-enc-no_AAD     875 KiB took 1.007 seconds,  868.579 KiB/s
AES-256-GCM-dec-no_AAD     900 KiB took 1.024 seconds,  879.291 KiB/s
GMAC Table 4-bit             2 MiB took 1.000 seconds,    2.488 MiB/s
CHACHA                       6 MiB took 1.004 seconds,    6.397 MiB/s
CHA-POLY                     4 MiB took 1.001 seconds,    4.024 MiB/s
POLY1305                    21 MiB took 1.000 seconds,   20.868 MiB/s
SHA                          6 MiB took 1.000 seconds,    6.493 MiB/s
SHA-256                      2 MiB took 1.010 seconds,    2.224 MiB/s
SHA-384                      1 MiB took 1.013 seconds,    0.988 MiB/s
SHA-512                    975 KiB took 1.019 seconds,  956.876 KiB/s
SHA-512/224                775 KiB took 1.000 seconds,  774.960 KiB/s
SHA-512/256                  1 MiB took 1.024 seconds,    0.978 MiB/s
SHA3-224                     1 MiB took 1.001 seconds,    1.171 MiB/s
SHA3-256                     1 MiB took 1.013 seconds,    1.109 MiB/s
SHA3-384                   875 KiB took 1.017 seconds,  860.133 KiB/s
SHA3-512                   625 KiB took 1.032 seconds,  605.855 KiB/s
SHAKE256                     1 MiB took 1.013 seconds,    1.109 MiB/s
HMAC-SHA                     6 MiB took 1.001 seconds,    6.463 MiB/s
HMAC-SHA256                  2 MiB took 1.007 seconds,    2.206 MiB/s
HMAC-SHA384               1000 KiB took 1.012 seconds,  987.685 KiB/s
HMAC-SHA512                950 KiB took 1.010 seconds,  940.914 KiB/s
RSA     2048   public       226 ops took 1.004 sec, avg 4.442 ms, 225.121 ops/sec
RSA     2048  private         8 ops took 1.093 sec, avg 136.666 ms, 7.317 ops/sec
DH      2048  key gen        16 ops took 1.015 sec, avg 63.442 ms, 15.762 ops/sec
DH      2048    agree        16 ops took 1.009 sec, avg 63.034 ms, 15.864 ops/sec
ECC   [      SECP256R1]   256  key gen        46 ops took 1.034 sec, avg 22.489 ms, 44.466 ops/sec
ECDHE [      SECP256R1]   256    agree       108 ops took 1.004 sec, avg 9.292 ms, 107.615 ops/sec
ECDSA [      SECP256R1]   256     sign        42 ops took 1.017 sec, avg 24.226 ms, 41.278 ops/sec
ECDSA [      SECP256R1]   256   verify        96 ops took 1.015 sec, avg 10.569 ms, 94.614 ops/sec
CURVE  25519  key gen       103 ops took 1.006 sec, avg 9.762 ms, 102.433 ops/sec
CURVE  25519    agree       106 ops took 1.015 sec, avg 9.575 ms, 104.437 ops/sec
ED     25519  key gen       101 ops took 1.005 sec, avg 9.952 ms, 100.479 ops/sec
ED     25519     sign        80 ops took 1.019 sec, avg 12.741 ms, 78.484 ops/sec
ED     25519   verify        76 ops took 1.020 sec, avg 13.427 ms, 74.477 ops/sec
CURVE    448  key gen        25 ops took 1.014 sec, avg 40.580 ms, 24.643 ops/sec
CURVE    448    agree        26 ops took 1.034 sec, avg 39.770 ms, 25.144 ops/sec
ED       448  key gen        34 ops took 1.027 sec, avg 30.219 ms, 33.092 ops/sec
ED       448     sign        32 ops took 1.030 sec, avg 32.187 ms, 31.069 ops/sec
ED       448   verify        22 ops took 1.098 sec, avg 49.900 ms, 20.040 ops/sec
Benchmark complete

For the RP2040, you can expect around 33-50% of this performance at the default 125MHz.

wolfBoot support

We are not stopping at just plain wolfSSL, we have a port of wolfBoot in-development to allow for secure bootloading of the RP2350 microcontroller. We will announce more details about this soon.

How do I try this?

We have a wolfSSL example available in our wolfSSL Examples repository. For more information, you can reach out to us for help at facts@wolfSSL.com or +1 425 245 8247.

Download wolfSSL Now

Posts navigation

1 2 3