RECENT BLOG NEWS

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

wolfSSL FIDO Compliance

As organizations move away from traditional password-based authentication, FIDO (Fast Identity Online) has emerged as one of the leading standards for strong authentication. wolfSSL is positioned to support this transition with our robust cryptography library, wolfCrypt, which implements many of the core algorithms required for FIDO compliance. This blog outlines how wolfSSL can serve as a foundation for FIDO-compliant authentication solutions.

FIDO and Why It Matters

FIDO (Fast Identity Online) Alliance maintains strict standards for cryptographic implementations in authentication systems with a mission to reduce the reliance of passwords. With wolfCrypt implementing most of the FIDO-approved algorithms, this means wolfSSL can provide developers with a compliant cryptographic foundation for their FIDO authentication solutions for both large, web-connected systems as well as embedded microcontrollers.

Existing FIDO-Approved Algorithms

wolfSSL already implements many of the cryptographic algorithms from FIDO’s allowed cryptography list^[1], including:

• SHA-256, SHA-384, SHA-512, SHA3-256, SHA3-384 and SHA3-512
• HMAC capabilities with the allowed hash functions
• HMAC implementation for secure message authentication
• AES-CMAC support for lightweight authentication
• AES-GCM for authenticated encryption
• RSA PSS and PKCS#1 v1.5 signature support
• Ed25519 signatures

The only missing algorithms in wolfSSL are the implementation of ED256, ED256-2, ED512 and ED638.

wolfSSL also meets FIDO’s deterministic random number/bit generator requirements as wolfCrypt is NIST FIPS 140-2/3 compliant which uses NIST SP800-90A HASH_DRBG as well as NIST SP800-90B compliant entropy generation.

Potential Integration with FIDO2 Applications and Libraries

FIDO2 is the latest authentication standard that enables passwordless and strong two-factor authentication through the Web Authentication (WebAuthn) API and Client-to-Authenticator Protocol (CTAP). With there already being FIDO2 applications on the market wolfSSL can easily be implemented directly or automatically with the compatibility layer or engine/provider OpenSSL replacement. For instance Yubico’s libfido2 library which uses OpenSSL could be ported to use wolfCrypt instead.

A wolfSSL employee has also been working on a project that uses 2FA with wolfCrypt on a Raspberry Pi Pico called Fidelio.

FIPS 140-3 and FIDO2

Organizations requiring both FIDO2 and FIPS 140-3 compliance can leverage wolfCrypt’s FIPS 140-3 validated module, which provides CAVP and FIPS validated implementations of essential FIDO algorithms. This dual compliance ensures solutions meet both authentication standards and regulatory requirements.

Looking Forward

Contact us at facts@wolfSSL.com or +1 425 245 8247 for question about comprehensive support for integrating wolfCrypt into your FIDO2 applications, including:

• Technical consultation for implementation
• Documentation and example code
• Integration with hardware security modules
• Optimization for embedded systems
• Custom builds for specific platforms

Resources

^[1] “FIDO Authenticator Allowed Cryptography List,” FIDO Alliance, 2023.

Download wolfSSL Now

wolfSSL now has support for Renesas RX TSIP with ECDSA and crypto callbacks. This update provides broader flexibility and security for embedded systems with Renesas RX TSIP. Below is a summary of the key changes and updates that were added in PR# 7685:

Key Changes and Features

1. Renesas RX TSIP with ECDSA Support
   WolfSSL now fully supports ECDSA on Renesas RX TSIP, which adds greater functionality when generating signatures. The update also adds support for raw R+S signatures.
2. ECC with NO_ASN
   You can now use ECC support without ASN.1 encoding by using the configuration:
   ‘./configure –enable-cryptonly –disable-rsa –disable-asn –disable-examples’
   This can decrease the overhead in environments where you don’t need ASN.1 support.
3. RX TSIP Crypt Configuration Fixes
   These changes also fixes issues with WOLFSSL_RENESAS_TSIP_CRYPTONLY and NO_WOLFSSL_RENESAS_TSIP_CRYPT_HASH macros, allowing for builds to complete smoothly when there is only a requirement for cryptography operations.
4. Reverted wc_GenerateSeed Support
   wc_GenerateSeed on the RX TSIP was reverted. This ensures compatibility with the updated RNG on RX TSIP.
5. Updated Client Authentication Key Data
   Example key data with private key for client authentication has been updated.

Testing

These changes were tested using the e2Studio IDE, and tests were verified including client and server examples.

Conclusion

These updates extend wolfSSL’s support of the Renesas RX TSIP to include ECDSA and Raw R+S signature support, greatly improving flexibility and optimizing the build for embedded systems. If you have questions about any of the above, please contact us at facts@wolfSSL.com or +1 425 245 8247.

Download wolfSSL Now

At wolfSSL, we are committed to supporting a wide range of platforms and architectures, ensuring that our SSL/TLS library can be used across various environments. One of the platforms we continue to support is PowerPC, both in 32-bit and 64-bit configurations.

The latest updates to our PowerPC support primarily focus on resolving compatibility issues with Darwin (macOS) systems. The recent changes in the pull request https://github.com/wolfSSL/wolfssl/pull/7931 do not introduce any new features or modify existing functionality. These updates include:

• PowerPC Macros: Adjustments ensure compatibility with Darwin, allowing smooth builds on macOS.
• Assembler Compatibility: We’ve addressed issues with how registers are prefixed in the Darwin ABI ensuring compatibility with PowerPC systems.

Instead of adding register prefixes via a simple macro, we’ve opted for a more robust approach. This helps prevent potential issues in the future.

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

Download wolfSSL Now

The Extended Key Update extension for (D)TLS 1.3 is a draft proposal for a new key update mechanism. (D)TLS 1.3 lacks perfect forward secrecy (PFS) for long-lived sessions, leaving them vulnerable to key exfiltration attacks. The proposed Extended Key Update mechanism addresses this by incorporating minimal key exchanges during key updates. This safeguards connections by ensuring that even if session keys are compromised, past and future communications remain confidential.

This extension is ideal for environments where long uninterrupted secure connections are critical. By introducing PFS into key updates without requiring establishing new connections, it enhances security while maintaining availability. Its design also supports hybrid key exchanges, ensuring post-quantum readiness with a fallback to classical cryptography.

wolfSSL strives to provide the best security, and that is why we monitor new developments closely. If this extension is a feature you would be interested in, please write to us at facts@wolfSSL.com or call us at +1 425 245 8247.

Download wolfSSL Now

wolfSSL release 5.7.4 includes an exciting new feature. We have implemented Connection ID (CID) support for DTLS 1.2 (RFC 9146). CID is a new feature in DTLS 1.2 that allows for better handling of connection migration. Without it, DTLS connections are tied to the IP 5-tuple making it unable to recover the connection if one of the peers changes their address. This is where CID comes in. This feature is used to associate DTLS records from a new IP address to an existing connection. This is especially useful for mobile devices that may switch between Wi-Fi and cellular networks, or for any device that may change IP addresses during a connection.

Using CID’s in wolfSSL is easy. Just setup your connection as usual, but call wolfSSL_dtls_cid_use() to enable the CID feature on the connection. This will enable the CID on your side of the connection. To request the peer to use a CID, use wolfSSL_dtls_cid_set().

If you have any questions regarding CID’s in DTLS 1.2 or 1.3, please contact us at facts@wolfssl.com or +1 425 245 8247.

Download wolfSSL Now

wolfSSL has added support for libspdm 3.3.0. libspdm is the reference implementation of the DMTF’s Security Protocols and Data Models (SPDM specifications). The goal of the SPDM specifications is to provide device attestation and authentication as well as secure communication over any transport. Both wolfSSL and SPDM are designed to operate on any transport.

Our wolfCrypt library is the underlying cryptographic library used by wolfSSL. wolfCrypt is a lightweight, embeddable, and easy-to-configure crypto library. It supports all the algorithms used by SPDM such as AES, CHACHA, POLY-1305, SHA-3, RSA, ECC. wolfCrypt is FIPS 140-3 validated and is available under both open source and commercial licenses. wolfCrypt also supports the Chinese SM ciphers SM2, SM3, and SM4.

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

Download wolfSSL Now

Code Intelligence is happy to announce the discovery of a heap-based use-after-free vulnerability in wolfSSL, identified through a fuzz test automatically generated by an AI Test Agent. This marks another milestone in advancing automated security testing and demonstrates the power of AI-driven tools to improve software reliability and safety.

Discovery and Resolution

The vulnerability was identified during the final week of October 2024.

Remarkably, the discovery required no manual intervention—beyond setting up the project and typing “cifuzz spark” into the command line. This fuzz test, automatically generated and executed by Spark, the AI Test Agent, uncovered the critical data that exposed the flaw.

Spark, the AI Test Agent, is an enhancement to ?ode Intelligence’s fuzz testing product CI Fuzz. Leveraging LLMs and advanced static analysis, it autonomously identifies the most critical functions in the codebase to fuzz, generates and runs fuzz tests, and thus, finds bugs and vulnerabilities.

Spark will be publicly demonstrated to the security and software development community on January 28, 2025. Secure your free spot here.

Spark uncovered the vulnerability in wolfSSL during its final beta testing. Code Intelligence reported the issue to the wolfSSL team immediately, and they responded with exceptional efficiency, resolving the vulnerability within 3 days.

The fix was officially included in release wolfSSL 5.7.6 on 31 December 2024.

In the only manual step, Peter Samarin from Code Intelligence has assessed and confirmed that the vulnerability exists and is exploitable under specific conditions.

We encourage developers to update to the latest version of wolfSSL to mitigate any potential risks.

What Is a Heap-Based Use-After-Free?

A heap-based use-after-free vulnerability occurs when a program continues to access memory on the heap after it has been freed.

In a typical scenario, a program allocates memory, uses it, and then frees it. However, if there is a mistake in memory management, such as a dangling pointer, a subsequent access attempt may interact with memory that has already been reallocated for another use.

This can lead to unexpected behavior, crashes, or—more worryingly—security exploits that allow attackers to execute arbitrary code or manipulate program behavior maliciously.

We are grateful to the Code Intelligence team for uncovering and reporting the vulnerability to us. You can explore the technical details of the issue in Code Intelligence’s blog post.

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

Download wolfSSL Now