Category: wolfSSL/ wolfCrypt

We are excited to announce the creation of mcwolf, a new project that brings a Classic McEliece post-quantum cryptographic algorithm implementation and integration to wolfSSL. We would like to thank Daniel J. Bernstein for the integration work that went into mcwolf.

The mcwolf project is a series of scripts and patches against wolfSSL that adds support for Classic McEliece, a code-based post-quantum cryptographic algorithm that is deployed in various applications (see https://mceliece.org) and is under consideration for standardization by ISO. The project uses the official vec implementation of Classic McEliece, providing a portable solution that can be optimized for various platforms. This implementation vectorizes across 64-bit integers.

The project’s page can be found here.

Why Classic McEliece?

Post-quantum cryptographic algorithms like Classic McEliece are designed to resist attacks from both classical and quantum computers, ensuring long-term security for sensitive data.

Classic McEliece is particularly known for its:

• Strong security foundations based on the well-studied McEliece cryptosystem with a long pedigree dating back to 1978
• Relatively small ciphertext sizes compared to other post-quantum KEMs

Technical Details

The mcwolf project has several notable characteristics:

• Uses the official vec implementation of Classic McEliece, which is portable across platforms
• Includes comprehensive testing, with the same code being extensively tested in SUPERCOP and libmceliece

The implementation supports various parameter sets for Classic McEliece, including:

• mceliece348864
• mceliece348864pc
• mceliece460896
• mceliece460896pc
• mceliece6688128
• mceliece6688128pc
• mceliece6960119
• mceliece6960119pc
• mceliece8192128
• mceliece8192128pc

How to Build mcwolf

Building mcwolf is straightforward. Go to https://cr.yp.to/2025/20250426-mcwolf/notes.html and download the build script. Mark it as executable and run the script on your linux machine. You need curl, python3, git, autoconf, libtool and generic gcc build tools already installed.

The mcwolf implementation includes tests that are integrated into the existing testing framework. Here is some expected output:

 ...
 MCELIECE348864 test passed!
 MCELIECE460896 test passed!
 MCELIECE6688128 test passed!
 MCELIECE6960119 test passed!
 MCELIECE8192128 test passed!
 ...
------------------------------------------------------------------------------
  wolfSSL version 5.8.0
 ------------------------------------------------------------------------------
 Math: ??????Multi-Precision: Wolf(SP) word-size=64 bits=4096 sp_int.c
 wolfCrypt Benchmark (block bytes 1048576, min 1.0 sec each)
 mceliece 348864  key gen   	100 ops took 4.492 sec, avg 44.922 ms, 22.261 ops/sec
 mceliece 348864	encap 	18100 ops took 1.005 sec, avg 0.056 ms, 18007.073 ops/sec
 mceliece 348864	decap  	6500 ops took 1.005 sec, avg 0.155 ms, 6466.727 ops/sec
 mceliece 460896  key gen   	100 ops took 14.307 sec, avg 143.068 ms, 6.990 ops/sec
 mceliece 460896	encap  	9800 ops took 1.005 sec, avg 0.103 ms, 9751.777 ops/sec
 mceliece 460896	decap  	2200 ops took 1.009 sec, avg 0.459 ms, 2180.508 ops/sec
 mceliece 6688128  key gen   	100 ops took 30.491 sec, avg 304.906 ms, 3.280 ops/sec
 mceliece 6688128	encap  	5900 ops took 1.007 sec, avg 0.171 ms, 5856.450 ops/sec
 mceliece 6688128	decap  	2000 ops took 1.001 sec, avg 0.500 ms, 1998.431 ops/sec
 mceliece 6960119  key gen   	100 ops took 27.325 sec, avg 273.249 ms, 3.660 ops/sec
 mceliece 6960119	encap  	6300 ops took 1.008 sec, avg 0.160 ms, 6248.913 ops/sec
 mceliece 6960119	decap  	2100 ops took 1.022 sec, avg 0.487 ms, 2055.315 ops/sec
 mceliece 8192128  key gen   	100 ops took 35.826 sec, avg 358.255 ms, 2.791 ops/sec
 mceliece 8192128	encap  	5500 ops took 1.001 sec, avg 0.182 ms, 5495.955 ops/sec
 mceliece 8192128	decap  	2100 ops took 1.044 sec, avg 0.497 ms, 2010.617 ops/sec

Conclusion

The mcwolf implementation brings another post-quantum cryptographic KEM to wolfSSL, helping to future-proof security-critical applications against the threat of quantum computing. We encourage the wider community to try out the mcwolf project!

From the wolfSSL team, we give our heart-felt thanks to Daniel J. Bernstein! Thank you Daniel!

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

We’re excited to announce that wolfSSL now officially supports the STM32WBA series of microcontrollers from STMicroelectronics! This addition broadens our commitment to providing lightweight, robust, and high-performance SSL/TLS solutions across a wide range of embedded platforms.

What is the STM32WBA Series?

The STM32WBA series is a family of ultra-low-power wireless microcontrollers designed to bring advanced Bluetooth® Low Energy (LE) connectivity to IoT and embedded devices. Built around the Arm Cortex-M33 core with TrustZone security and integrated radio, STM32WBA microcontrollers are optimized for secure, connected applications in healthcare, industrial, and smart home environments.

Why This Matters

By integrating wolfSSL with STM32WBA, developers now have:

• Seamless TLS/SSL support for Bluetooth LE and IP-based connectivity.
• Optimized performance with wolfSSL’s small footprint and STM32’s hardware acceleration features.
• Ease of integration with STM32Cube ecosystem tools and examples to get started quickly.

Key Highlights:

• Full TLS 1.3 and DTLS 1.3 support.
• Hardware crypto acceleration using STM32WBA’s on-chip crypto engine.
• Support for wolfCrypt’s entire crypto-suite (including Post-Quantum Cryptography).
• Example projects for STM32CubeIDE and STM32CubeMX to simplify setup.

To explore wolfSSL on STM32WBA, check out our STM32 Cube Pack instructions and examples here.

For more information on wolfSSL and how it integrates with the STM32WBA, visit our documentation or reach out to our team at facts@wolfSSL.com or +1 425 245 8247.

Download wolfSSL Now

Release 5.8.0 of our wolfSSL library implements hybrid key exchange algorithms that combine conventional elliptic curve cryptography with post-quantum key encapsulation mechanisms (KEMs).

New Hybrid Groups: Combining elliptic curves (SECP256/384/521, X25519, X448) with ML-KEM. This provides compatibility with Chromium and other organizations that are together with wolfSSL leading the way in post-quantum migration. Some of the new hybrid groups were already done in previous releases. Here is the complete list of hybrid key exchange groups in TLS 1.3:

• WOLFSSL_P256_ML_KEM_512
• WOLFSSL_P384_ML_KEM_768
• WOLFSSL_P256_ML_KEM_768
• WOLFSSL_P521_ML_KEM_1024
• WOLFSSL_P384_ML_KEM_1024
• WOLFSSL_X25519_ML_KEM_512
• WOLFSSL_X25519_ML_KEM_768
• WOLFSSL_X448_ML_KEM_768

The new release includes comprehensive test configurations demonstrating how to use these new hybrid groups in TLS 1.3 connections. Go ahead and start thwarting the “Harvest Now, Decrypt Later” threat model that is currently in play.

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

We at wolfSSL would like to thank Goran Mahovlic and the entire Radiona team for inviting us to their headquarters in Zagreb, Croatia! We enjoyed the opportunity to present information on one of our flagship products, wolfBoot, during the recent OpenHardware Meet-up. The hospitality was outstanding and greatly appreciated!

Radiona is home to the awesome ULX3S FPGA + ESP32 board, first introduced to the general public by our friends over at the Crowd Supply Campaign and now available from Mouser Electronics.

Radiona embodies the true STEAM Spirit. So much more than the open source hardware is the community of passionate makers, students, engineers, and more. These people from all over the world participate in the Zagreb Makerspace and FER: the Faculty of Electrical Engineering and Computing at the University of Zagreb in Croatia.

A new and exciting board is also in the works from the collaboration between Radiona and Intergalaktik: the ULX4M! This is another open source FPGA board that has a CM4 connector for the many Raspberry Pi Carrier boards that accept a Compute Module.

The ULX3S is the only board (that we know of!) that is not only open source, but includes both open source FPGA and ESP32 projects, all on one board. Check out some of the many projects available.

New and exciting features will soon be added to the ULX3S, leveraging some of the features of the ESP32-S3. See the development README doc.

There’s extensive wolfSSL support for the ESP32, including not only Espressif ESP-IDF with optional Managed Components but also Arduino, PlatformIO, and more.

[gojimmypi] has several blogs on using wolfSSL with the ULX3S: Perhaps you’d like to SSH into the ESP32 on your ULX3S? That example leverages the core Espressif wolfSSH in the wolfssl-examples SSH-to-UART project.

The ULX3S could also be integrated into the Apple HomeKit ecosystem.

Interested in getting Started with wolfSSL on the ESP32? Check out our YouTube video:

See our prior blog about using the ULX3S FPGA to create your own soft-core RISC-V, the same Hazard3 core used on the Raspberry Pi Pico 2 RP2350.

Meet Us at Events:

• Upcoming wolfSSL events
  • CYSAT Europe | May 14-15
  • Barcelona Cybersecurity Congress | May 21-23

• Upcoming Radiona events
  • Radiona.org OpenLAB and Neo-retro Corner @ DORS/CLUC 2025 | May 22-23
  • Radiona Blogs

For more information:

• wolfSSL Docs
• wolfSSL Manual
• Other ESP32 blogs
• Learn more about Radiona and wolfSSL.

Post Quantum

Do you have code that can be upgraded to Post Quantum? Read our recent blog to learn more!

FIPS Certified!

When you are ready to move on to the next step, wolfSSL will be there for you! Need to have your project NIST Certified? Recently we announced that wolfSSL is the First in the World to offer FIPS 140–3 Automated Submission with our NIST Certificate #4718.

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

Summary

A critical security incident exposed KeyPlug malware infrastructure due to the improper use of wolfSSL test certificates in production. The 24-hour exposure revealed sophisticated attack tools linked to the RedGolf/APT41 threat group, demonstrating how poor certificate management can compromise even advanced threat actors’ operations.

The Certificate Failure

The compromised server was identified through its WolfSSL test certificate:

Subject Common Name: www[.]wolfssl[.]com
Subject Organizational Unit: Support_1024
Issuer Organizational Unit: Consulting_1024
SHA-256: 4C1BAA3ABB774B4C649C87417ACAA4396EBA40E5028B43FADE4C685A405CC3BF

Critical Issues

• Test Certificate Misuse
  • Production use of wolfssl.com test domain
  • Weak 1024-bit keys (indicated by “_1024” suffix)
  • Certificate sharing across multiple attack servers
• Security Impact
  • Exposed Fortinet exploitation tools and C2 infrastructure
  • Enabled infrastructure correlation through shared certificates
  • Compromised operational security of advanced threat actors

Best Practices for WolfSSL Implementation

To avoid security lapses like the one described, it’s critical to follow best practices when deploying wolfSSL in production environments. The following guidelines focus on certificate requirements, security controls, and monitoring techniques:

Production Deployments

• Certificate Requirements
  • Use only trusted CA-issued certificates
  • Implement minimum 2048-bit RSA keys
  • Maintain proper validation chains
• Security Controls
  • Never use test certificates in production
  • Implement certificate pinning
  • Regular certificate rotation

Monitoring and Detection

• Certificate Auditing
  • Regular infrastructure scans
  • Certificate inventory management
  • Automated validation checks
• Warning Signs
  • Domains containing “wolfssl.com”
  • Organizational units with test indicators
  • Key sizes below 2048 bits
  • Invalid trust chains

Recommendations

To mitigate risk and ensure strong certificate hygiene, both WolfSSL users and security teams should take immediate action. Below are tailored recommendations for each group:

Immediate Actions

1. For WolfSSL Users
   • Audit all certificates
   • Remove test certificates
   • Implement CA-issued certificates
   • Verify proper key lengths
2. For Security Teams
   • Monitor for test certificate usage
   • Implement certificate validation
   • Regular infrastructure scanning
   • Maintain certificate inventory

Conclusion

Organizations must maintain strict separation between development and production certificates and implement proper certificate management policies to prevent similar exposures.

Please do not use wolfSSL test certificates in production because the corresponding private keys are published as part of the wolfSSL source code package, so by design, these certificates are insecure. The test certificate private keys are public!

Source:

• KeyPlug-Linked Server Briefly Exposes Fortinet Exploits, Webshells, and Recon Activity Targeting a Major Japanese Company
• Exposed KeyPlug Malware Staging Server Contains Fortinet Firewall and VPN Exploitation Scripts

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 evolving landscape of cryptographic security, supporting multiple signature algorithms within a single certificate has become increasingly important. These certificates are known as Chimera certificates, a moniker coined by the X9.146 banking standards team. They provide enhanced security, flexibility, and agility, especially for the transition to post-quantum cryptography. As well, wolfSSL also understands the new TLS 1.3 CKS extension as defined by the X9.146 banking standard draft.

Chimera certificates are X.509 certificates that contain two public keys and signatures. These certificates are implemented through the use of three extensions:

• Subject Alternative Public Key Info (SAPKI): Contains an alternative public key
• Alternative Signature Algorithm: Specifies the algorithm used for the alternative signature
• Alternative Signature Value: Contains the actual bitstring of the alternative signature

In X.509 certificates, extensions can be marked as either “critical” or “non-critical.” Critical extensions MUST be understood and processed by the certificate validator. If a validator doesn’t recognize a critical extension, it MUST reject the certificate. Non-critical extensions can be safely ignored if not understood.

Before release 5.8.0, wolfSSL’s dual algorithm certificate implementation did not properly support the parsing of these extensions if they were marked as Critical. This was because the whole purpose of these extensions was to facilitate migration by allowing unmigrated systems to ignore the alternative public key and signatures. In that context, marking these extensions as critical made no sense.

That said, these extensions are standardized in the 2019 edition of the ITU-T X.509 standard. In that document, under recognition that there might be other future applications for these extensions, marking these extensions as critical is permitted.

The addition of critical extension support for Chimera certificates extensions represents an important compliance step. Without standards, interoperability would not be possible.

As the cryptographic landscape continues to evolve, especially with the ongoing transition to post-quantum algorithms, enhancements such as Chimera certificate support will become increasingly valuable. wolfSSL continues to demonstrate its commitment to providing a robust, standards-compliant, and forward-looking cryptographic library.

If you have question about any of the above, please contact us at >a href=”mailto”facts@wolfssl.com”>facts@wolfSSL.com or call us at +1 425 245 8247.

Download wolfSSL Now

We are excited to announce that wolfSSL version 5.8.0 is now available. This release brings several important new features and improvements. Below are the key new additions:

New Features

• Implemented various fixes to support building for Open Watcom, including OS/2 support and Open Watcom 1.9 compatibility (PR 8505, 8484).
• Added support for STM32H7S (tested on NUCLEO-H7S3L8) (PR 8488).
• Added support for STM32WBA (PR 8550).
• Added Extended Master Secret Generation Callback to the –enable-pkcallbacks build (PR 8303).
• Implemented AES-CTS (–enable-aescts) in wolfCrypt (PR 8594).
• Added support for libimobiledevice commit 860ffb (PR 8373).
• Initial ASCON hash256 and AEAD128 support based on NIST SP 800-232 IPD (PR 8307).
• Added blinding option when using a Curve25519 private key by defining the macro WOLFSSL_CURVE25519_BLINDING (PR 8392).

ML-DSA and Post-Quantum Cryptography Enhancements

In line with NIST’s latest documentation, wolfSSL has updated its Dilithium implementation to ML-DSA (Module-Lattice Digital Signature Algorithm), which is fully supported in this release. Additionally, the release includes updates to further optimize ML-DSA and LMS (Leighton–Micali Signature) schemes, reducing memory usage and improving performance.

Linux Kernel Module (linuxkm) Updates

wolfSSL 5.8.0 expands support for the Linux Kernel Module (linuxkm), with several important enhancements to improve kernel-level cryptographic integration. This includes extended LKCAPI registration support for rfc4106(gcm(aes)), ctr(aes), ofb(aes), ecb(aes), and the legacy one-shot AES-GCM backend. Compatibility improvements have been added for newer kernels (?6.8), and calls to scatterwalk_map() and scatterwalk_unmap() have been updated for Linux 6.15. The release also registers ECDSA, ECDH, and RSA algorithms with the kernel crypto API and introduces safeguards for key handling, including forced zeroing of shared secrets. These changes make it possible to use more wolfSSL functionality in the kernel space.

For a full list of fixes and optimizations check out the ChangeLog.md bundled with wolfSSL. Download the latest release from the download 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

The NXP Application Code Hub, in collaboration with wolfSSL, now provides developers with a practical foundation for building secure IoT applications using NXP’s MCUXpresso VS Code extension.

This ecosystem combines NXP’s powerful microcontrollers with wolfSSL’s security libraries, all running on the Zephyr RTOS.

Available Initial Examples:

• wolfMQTT publisher client with zephyr
  • Implements a secure MQTT client for real-time data publishing.
• wolfSSH RGB server with zephyr
  • Features an SSH server with remote RGB LED control capabilities.
• wolfSSL tls hello server with zephyr
  • Shows basic TLS v1.3 server implementation with secure communication.

These examples are initially designed specifically for NXP’s FRDM-MCXN947 development board, but because they are using Zephyr they can easily be adapted to any board or chip supported by Zephyr and NXP!

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