RECENT BLOG NEWS

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:

• Safe bindings can be developed on top of our validated cryptography engine
• Reduced risk of implementation errors
• Enhanced security through compile-time checks

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 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

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

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