RECENT BLOG NEWS

So, what’s new at wolfSSL? Take a look below to check out the most recent news, or sign up to receive weekly email notifications containing the latest news from wolfSSL. wolfSSL also has a support-specific blog page dedicated to answering some of the more commonly received support questions.

AI-automated fuzz testing uncovered a vulnerability in wolfSSL

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

wolfSSL SSSD Support

We have ported the System Security Services Daemon (SSSD) to use wolfSSL for its SSL/TLS support. SSSD provides a set of daemons that allow access to identity and authentication providers. SSSD is used to connect to remote directories and authentication mechanisms such as LDAP, Kerberos, or FreeIPA. The wolfSSL SSSD port allows organizations to leverage the performance and size advantages of wolfSSL for their SSSD deployments.

wolfSSL is a lightweight and portable SSL/TLS library written in C. It supports industry standards up to the current TLS 1.3 and DTLS 1.3 levels, is far smaller than OpenSSL, offers a simple API, an OpenSSL compatibility layer, and includes FIPS 140-3 validated cryptography. By integrating wolfSSL with SSSD, organizations can benefit from enhanced performance, reduced memory footprint, and robust security features, making it an ideal choice for secure identity and authentication services.

The patch and installation instructions for SSSD are available here. If you have any questions regarding this or any other port, please contact us at facts@wolfssl.com or +1 425 245 8247.

Download wolfSSL Now

wolfSSL Support for STM32G4

wolfSSL now has support for STM32G4 microcontrollers. With new features that enable better performance and flexibility for cryptographic operations on STM32G4 hardware. Below is a summary of the key changes and updates that were made in PR #7997:

Key Changes and Features

  1. User Settings Synchronization:
    The `user_settings_stm32.h` configuration file has been synchronized with the STM32Cube IDE’s `default_conf.ftl`. This ensures that the configurations are up to date and consistent with the STM32G4 environment.
  2. New Configuration Options:
    WOLF_CONF_IO: This option allows the user to select the network stack to use.
    Options include:

    • 1 = User IO (custom)
    • 2 = LWIP (POSIX)
    • 3 = LWIP (native )

    WOLF_CONF_RESUMPTION: This option controls session caching and session ticket functionality.

    • 0 = No session cache
    • 1 = Session cache / Session tickets

    WOLF_CONF_TPM: Enables TPM support, which adds Crypto Callbacks, Public MP, and AES CFB support.
    WOLF_CONF_PK: TLS Key Callbacks fir better key management in cryptographic operations.
    WOLF_CONF_AESGCM: Support for AES GCM encryption modes with:

    • 1 = GCM_SMALL
    • 2 = GCM_TABLE_4BIT

Testing

The code was compiled in STM32CubeIDE for STM32G491x, but no hardware was available for testing at the time. Tests have been run with essential hardware features, including:

  • – RTC
  • – RNG
  • – LPUART1
  • – ARM ASM

Conclusion

wolfSSL now supports STM32G4 microcontrollers, which has custom IO, session caching, TPM support, and AES GCM 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

wolfSSL Supports TSIP v1.21

wolfSSL 5.7.4 adds support for Renesas TSIP v1.21 on RX72N and RX65N platform. The RX72N and RX65N are the flagship models of RX series, using a 32-bit, 240 MHz on RX72N, and 120 MHz on RX65N. Using the TSIP driver, wolfSSL can offload supported cryptographic and TLS operations on the underlying Renesas hardware for increased performance. TSIP v1.21 is the latest version released in 2024. By updating the driver, it offers better performance and stability than previous versions.

Check out wolfSSL Renesas TSIP support here.

Example applications for Renesas RX series MCUs with Renesas IDE e2studio project files are provided in the wolfSSL package, included in the /IDE/Renesas/e2studio/RXxx folders. Detailed instruction manuals written both in English and Japanese will help you get started with wolfSSL on these platforms quickly.

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

Download wolfSSL Now

New Year New Release: Introducing wolfSSL 5.7.6

Welcome 2025 with boundless possibilities and stronger security! We are excited to introduce wolfSSL 5.7.6, the latest update in open-source cybersecurity! Designed with the cleanest code, this release is packed with exciting enhancements:

  • Expanded Hardware Support: wolfSSL hardware support now includes RP2350 and STM32MP135F, with enhanced capabilities for RP2040 and Renesas TSIP.
  • Enhanced APIs: APIs introduced for simplified Curve25519 key decoding, stateless DTLS CID on the server side, and CRL callbacks.
  • Post-Quantum Cryptography Advances: Updated Post-Quantum ML-DSA features include parsing security levels from the DER encoding and expanded build options.

Dive into the ChangeLog for complete details on what wolfSSL 5.7.6 has to offer and start your year with a solution that works seamlessly right out of the box!

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

Download wolfSSL Now

Rust vs C: Navigating Language Choices in Embedded Systems and Cryptography

Introduction

In the world of low-level programming, particularly in embedded systems and cryptography, the choice between Rust and C remains a critical decision for development teams. This blog post explores the key differences, strengths, and trade-offs between these two powerful languages.

Our Rust Journey

As a company rooted in C and cryptographic solutions, we are exploring Rust’s potential. Our primary initiative is a rustls cryptographic provider (announcement) that integrates our cryptography engine.

Currently, our Rust efforts are exploratory. We’ve observed growing interest in safe Rust bindings. These Rust initiatives allow us to evaluate the language’s potential without disrupting our technological foundation.

Language Fundamentals

C: The Established Standard

C has been the backbone of systems programming for decades. Its strengths lie in:

  • Direct memory manipulation
  • Minimal runtime overhead
  • Extensive legacy codebase and tooling
  • Wide platform support
  • Low-level control over system resources

Rust: The Modern Systems Programming Language

Rust offers a modern approach to systems programming, with a focus on:

  • Memory safety without garbage collection
  • Zero-cost abstractions
  • Comprehensive compile-time checks
  • Modern language features
  • Explicit error handling

Safety and Memory Management

C: Manual Memory Management

  • Requires manual memory allocation and deallocation
  • Prone to common errors like buffer overflows, dangling pointers, and memory leaks
  • No built-in protection against undefined behavior
  • Requires significant developer expertise to write secure code

Rust: Compile-Time Safety Guarantees

  • Ownership model prevents common memory-related bugs
  • Borrow checker ensures memory safety at compile-time
  • Eliminates data races and many classes of concurrency bugs
  • Provides safe abstractions without runtime performance penalty

Performance Considerations

C: Proven Performance

  • Minimal abstraction overhead
  • Direct mapping to machine instructions
  • Mature optimizing compilers
  • Ideal for performance-critical systems

Rust: Competitive Performance

  • Comparable performance to C
  • Zero-cost abstractions
  • Modern optimization techniques
  • Compile-time optimizations that reduce runtime checks

Embedded Systems and Cryptography Context

Cryptographic Considerations

  • C requires extensive manual validation and review
  • Rust provides built-in mechanisms to prevent common cryptographic implementation errors
  • Rust’s type system and borrow checker can catch many potential security vulnerabilities during compilation

FIPS 140-3 Validation

For organizations like ours working on FIPS-validated cryptographic modules, Rust offers promising opportunities:

Embedded Rust Ecosystem Challenges

The embedded systems landscape presents significant challenges for Rust support. Microcontroller silicon vendors predominantly develop their platforms using C-based software development kits and hardware abstraction layer (HAL). While the embedded HAL crate shows promise, and some vendors are exploring Rust implementations, the ecosystem remains largely C-centric.
The transition from C to Rust represents, as of now, a gradual evolution rather than an immediate transformation.

Are you working with Rust?

Are you interested in Rust solutions with wolfSSL integration, or do you have questions about any of the above? If so, reach out to us at facts@wolfSSL.com or call us at +1 425 245 8247.

Download wolfSSL Now

Kick-off 2025 with the New and Updated Getting Started Webinar Series

Kick off 2025 with wolfSSL’s New and Updated Getting Started Webinar Series! From January 6th to January 10th, join us for a week of in-depth, hands-on learning in our “Foundational Learning to Get You Started in 2025: New and Updated Getting Started Webinar Series.” Led by wolfSSL senior engineers, this series will cover the foundational concepts and advanced techniques you need to tackle secure communication challenges with confidence. By the end of the week, you’ll walk away with the skills and knowledge to integrate these technologies into your projects and enhance your embedded security solutions.

Mark your calendars and secure your spot for one or all of our sessions!

Foundational Learning to Get You Started in 2025 Schedule:

  • January 6th | 9 AM PT
    New and Updated: Getting Started with wolfTPM

    Join us on January 6th at 9 AM PT for an in-depth exploration of wolfTPM. Learn the fundamentals of TPM 2.0 and how wolfTPM can enhance the security of your embedded systems. Explore build options, navigate the wolfTPM API, and dive into real-world use cases. By the end of the webinar, you’ll have the skills to integrate wolfTPM into your platform and protect against emerging security threats.
    Register Now

  • January 7th | 9 AM PT
    New and Updated: Getting Started with wolfBoot

    Join us on January 7th at 9 AM PT for an exclusive webinar, Getting Started with wolfBoot. This session will cover the fundamentals of wolfBoot, including how to configure, deploy, and optimize this secure boot solution for embedded systems. You’ll gain valuable insights into managing keys, customizing memory layouts, and implementing secure firmware updates to address modern security challenges.

    Register Now

  • January 8th | 10 AM PT
    New and Updated: Getting Started with wolfMQTT

    Join us on January 8th at 10 AM PT to master secure and reliable communication with wolfMQTT! Discover the basics of the MQTT protocols, key features of wolfMQTT, and how it integrates with wolfSSL TLS for secure communication. You’ll also explore configuration processes, wolfMQTT’s architecture, and real-world examples to confidently enhance your embedded communication projects.
    Register Now

  • January 9th | 10 AM PT
    New and Updated: Getting Started with curl

    Start 2025 by enhancing your URL transfer skills with libcurl! Join an exclusive webinar with curl creator Daniel Stenberg to explore the fundamentals of libcurl, its versatile protocol support, and best practices for implementation. Gain insights into API principles, non-blocking transfers, troubleshooting, and more to elevate your expertise in secure and efficient data transfers.
    Register Now

  • January 10th | 9 AM PT
    New and Updated: Getting Started with wolfSSL

    Join us on January 10th at 10 AM PT to master wolfSSL, the leading Embedded SSL/TLS library! In this webinar, learn how to utilize wolfSSL for secure communications and embedded system security. Explore SSL/TLS protocols, navigate the library structure, build and integrate wolfSSL into projects, and use wolfCrypt for testing and benchmarking. Plus, see these concepts in action through a live demo to boost your expertise.
    Register Now

Don’t miss this opportunity to start the year strong! Register today and take the first step toward mastering secure communication and enhancing your embedded projects with wolfSSL’s powerful tools and technologies!

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

Special Rules for LMS and XMSS

A while back, NIST (National Institute for Standards and Technology) came out with Special Publication 800-208 titled “Recommendation for Stateful Hash-Based Signature Schemes”. The full document can be found here.

It was very specific and strongly stated that you need to be very careful about how you do key generation and signing using these algorithms. Here is a direct quote:

Implementations of the key generation and signature algorithms in this document shall only be validated for use within hardware cryptographic modules. The cryptographic modules shall be validated to provide FIPS 140-2 or FIPS 140-3 [19] Level 3 or higher physical security, and the operational environment shall be non-modifiable or limited. … The cryptographic module shall not allow for the export of private keying material. The entropy source for any approved random bit generator used in the implementation shall be located inside the cryptographic module’s physical boundary.

In a nutshell, once an LMS or XMSS private key is generated, there must only ever be one instance of it. No copies. Not even backups. The reason is that with multiple instances there is a chance for misuse of the state of the private key which would be catastrophic because it would require the revocation of the key pair. The standards that define the formats of the cryptographic artifacts even went so far as to leave the format of the private key undefined so that interoperability would be further hindered.

We understood this from the start. By using the –enable-lms or –enable-xmss flags you will get the full suite of operations: key generation, sign and verify. This will allow our customers to quickly start experimenting, prototyping and benchmarking with these algorithms without first having to go through the long process of finding an HSM vendor. Of course, once it comes time to use these algorithms in production, to reduce code size and guarantee compliance, the key generation and sign operations can be eliminated from the binary with the following flags: –enable-lms=verify-only or –enable-xmss=verify-only.

Here at wolfSSL, we’ve got you covered from start to finish.

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

Download wolfSSL Now

Post-Quantum CAVP Validations

Here at wolfSSL we love it when our partners achieve great things. We’d like to give a big shout out to our friends at Crypto4A for achieving a huge milestone by getting their CAVP (Cryptographic Algorithm Validation Program) validation. The details can be found here.

In summary, they got a Hardware validation for the QASM Cryptographic Module which stores, protects and manages cryptographic keys. Of very special note, their validation includes post-quantum algorithms LMS, ML-DSA, ML-KEM and SLH-DSA.

This is the same product that wolfSSL and Crypto4A use in an interoperability demonstration at the ICMC Conference in 2023. In that demonstration, the QASM signed a firmware image with LMS and wolfBoot was used to verify the firmware image against an LMS public key and signature and then booted the firmware. Preparations are underway for another demonstration where the QASM will be used to generate an ML-DSA certificate chain which will be used in a TLS 1.3 post-quantum connection using the wolfSSL library. The cryptographic operations will be done on an NXP iMX-93.

You can soon expect to see CAVP validation for wolfSSL’s post-quantum algorithm implementations in wolfCrypt as well. Want to see that effort accelerated and given a higher priority? Let us know and register your interest by sending a message to facts@wolfssl.com!

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

Download wolfSSL Now

Chameleons Scurrying into Your Protocols?

Hot on the heels of our work with dual algorithm certificates in TLS 1.3, it is now time to announce that we are going to be working on chameleon certificates! No, we are not talking about certified colour shifting lizards!

Chameleon certificates are specified in the IETF draft.

While it might seem like a long document, most of it is a listing of test vectors and the text is quite accessible; even for non-technical readers. That said, if you are looking for a summary of what these certificates do, read on.

The draft RFC defines an X.509 certificate extension for specifying how to overwrite certain fields of the certificate that contains it to transform that certificate into another certificate. Essentially this means you have 2 certificates in one!

So how does this relate to dual algorithm certificates? Well, it can serve the same function as a dual algorithm certificate. It can allow 2 algorithms to sign the same certificate! It is a new way to do hybrid certificates.

Want to learn more or have questions about any of the above? Sending us a message to facts@wolfssl.com or call us at +1 425 245 8247.

Download wolfSSL Now

Posts navigation

1 2 3 … 6 7 8 9 10 11 12 … 198 199 200

Weekly updates

Archives