RECENT BLOG NEWS
wolfSSL 5.8.0 Released
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
802.1AE-MACsec with wolfCrypt
What is 802.1AE?
802.1AE (MACsec) is a network layer 2 protocol for protecting ethernet frames with encryption and authentication across ethernet links. It introduces a new MACsec ethernet frame format, which carries an additional security tag (SecTAG) field inserted between the ethernet header and payload, as well as an integrity check value (ICV) trailer field at the end.
MACsec is built on the Galois/Counter Mode (GCM) construction, and uses AES-GCM to encrypt and integrity check ethernet payloads. It also supports an integrity-only mode of operation, where payloads are sent cleartext and GMAC is used for the ICV. It should be noted there is no “encrypt-only” MACsec mode, as integrity checks and origin authentication are fundamental to its design and choice of AES-GCM/GMAC.
Hop-by-hop vs end-to-end
The network topology of MACsec is fundamentally different from that of TLS or IPsec. MACsec protects data “hop-by-hop” along individual ethernet links, and does not have a concept of larger scale “end-to-end” protection as is the case between IP addresses in IPsec, or between network sockets in TLS.
There are benefits to this narrower scope. By protecting data only along individual ethernet links, there is no need to manage connection or session state across an entire network, which means latency is low. Also, the hop-by-hop scope allows for incremental deployment of MACsec, and utilization of device hardware acceleration along individual links.
This difference in scope means that MACsec is purely complementary to TLS and IPsec, and typically will be used in layered topologies (IPsec over MACsec, TLS over MACsec, etc). Furthermore, 802.1AE specifies nothing about key management and establishing MACsec, and typically will rely on higher level constructions such as EAP over TLS for provisioning.
Because MACsec happens hop-by-hop along ethernet links, it is typically implemented at a lower level by specialized devices and drivers: e.g. MACsec PHY hardware, or in the linux kernel as a specialized MACsec network driver. These will utilize hardware acceleration, and will have the added benefit of isolating key material to the device or kernel. The linux kernel is an especially interesting case that we’ll consider next.
MACsec in the linux kernel with wolfCrypt
The kernel MACsec driver itself does not contain any cryptographic implementations. Instead, it utilizes the kernel crypto API to allocate transforms for performing AES-GCM and GMAC on ethernet payloads. The kernel crypto API functions similar to a provider framework: different kernel modules register their cryptographic drivers, which in turn are used by device drivers for e.g. filesystem and network encryption. This makes sense, as cryptography in kernel-space has a number of strong advantages over user-space.
wolfSSL’s kernel module now supports registering wolfCrypt algorithms in the kernel crypto API (e.g. they will become listed in /proc/crypto). This means when kernel device drivers allocate cryptographic transforms for e.g. encrypted filesystems, IPsec, or MACsec, they are getting wolfCrypt’s registered implementations! In the case of wolfCrypt FIPS, one now has a very simple recipe for getting FIPS crypto into the linux kernel.
There are interesting possibilities with this. One could hypothetically have triple-layered network protection (TLS over IPsec over MACsec), with each utilizing wolfCrypt FIPS at different OSI layers!
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
Benchmarking wolfCrypt on the Frontgrade Gaisler GR740: A Glimpse into Performance
In the context of the recent collaboration between wolfSSL and Frontgrade Gaisler, we are excited to share some benchmark results of the wolfCrypt library running on the Gaisler GR740-MINI board.
The GR740, designed as ESA’s Next Generation Microprocessor (NGMP), is a radiation-hardened System-on-Chip (SoC) featuring a quad-core fault-tolerant LEON4 SPARC V8 processor.
WolfSSL and Gaisler aim to enhance security solutions for space-grade applications, leveraging the robust capabilities of the GR740 processor and the cryptographic know-how of wolfSSL.
Benchmark for wolfCrypt running on Baremetal:
------------------------------------------------------------------------------ wolfSSL version 5.8.0 ------------------------------------------------------------------------------ Math: Multi-Precision: Wolf(SP) word-size=32 bits=4096 sp_int.c Single Precision: ecc 256 384 rsa/dh 2048 3072 4096 sp_c32.c small wolfCrypt Benchmark (block bytes 1024, min 1.0 sec each) AES-128-CBC-enc 3 MiB took 1.003 seconds, 3.432 MiB/s AES-128-CBC-dec 3 MiB took 1.002 seconds, 3.411 MiB/s AES-192-CBC-enc 3 MiB took 1.007 seconds, 2.958 MiB/s AES-192-CBC-dec 3 MiB took 1.005 seconds, 2.940 MiB/s AES-256-CBC-enc 3 MiB took 1.005 seconds, 2.601 MiB/s AES-256-CBC-dec 3 MiB took 1.001 seconds, 2.585 MiB/s AES-128-GCM-enc 475 KiB took 1.014 seconds, 468.300 KiB/s AES-128-GCM-dec 475 KiB took 1.015 seconds, 468.142 KiB/s AES-192-GCM-enc 475 KiB took 1.036 seconds, 458.356 KiB/s AES-192-GCM-dec 475 KiB took 1.037 seconds, 458.202 KiB/s AES-256-GCM-enc 450 KiB took 1.003 seconds, 448.872 KiB/s AES-256-GCM-dec 450 KiB took 1.003 seconds, 448.724 KiB/s GMAC Table 4-bit 546 KiB took 1.001 seconds, 545.432 KiB/s CHACHA 7 MiB took 1.002 seconds, 6.945 MiB/s CHA-POLY 4 MiB took 1.000 seconds, 4.466 MiB/s POLY1305 17 MiB took 1.001 seconds, 17.076 MiB/s SHA 10 MiB took 1.002 seconds, 9.675 MiB/s SHA-256 3 MiB took 1.003 seconds, 2.581 MiB/s SHA3-224 2 MiB took 1.011 seconds, 1.907 MiB/s SHA3-256 2 MiB took 1.003 seconds, 1.801 MiB/s SHA3-384 1 MiB took 1.014 seconds, 1.397 MiB/s SHA3-512 1 MiB took 1.021 seconds, 0.980 MiB/s HMAC-SHA 10 MiB took 1.001 seconds, 9.585 MiB/s HMAC-SHA256 3 MiB took 1.001 seconds, 2.561 MiB/s RSA 2048 public 78 ops took 1.017 sec, avg 13.035 ms, 76.715 ops/sec RSA 2048 private 2 ops took 1.480 sec, avg 739.794 ms, 1.352 ops/sec DH 2048 key gen 4 ops took 1.283 sec, avg 320.709 ms, 3.118 ops/sec DH 2048 agree 4 ops took 1.282 sec, avg 320.625 ms, 3.119 ops/sec ECC [ SECP256R1] 256 key gen 18 ops took 1.028 sec, avg 57.084 ms, 17.518 ops/sec ECDHE [ SECP256R1] 256 agree 18 ops took 1.025 sec, avg 56.947 ms, 17.560 ops/sec ECDSA [ SECP256R1] 256 sign 16 ops took 1.010 sec, avg 63.136 ms, 15.839 ops/sec ECDSA [ SECP256R1] 256 verify 10 ops took 1.145 sec, avg 114.465 ms, 8.736 ops/sec
Benchmark of wolfCrypt running in Linux Environment:
------------------------------------------------------------------------------ wolfSSL version 5.8.0 ------------------------------------------------------------------------------ Math: Multi-Precision: Wolf(SP) word-size=32 bits=4096 sp_int.c Single Precision: ecc 256 384 rsa/dh 2048 3072 4096 sp_c32.c small wolfCrypt Benchmark (block bytes 1048576, min 1.0 sec each) AES-128-CBC-enc 5 MiB took 1.502 seconds, 3.330 MiB/s AES-128-CBC-dec 5 MiB took 1.542 seconds, 3.242 MiB/s AES-192-CBC-enc 5 MiB took 1.737 seconds, 2.879 MiB/s AES-192-CBC-dec 5 MiB took 1.780 seconds, 2.810 MiB/s AES-256-CBC-enc 5 MiB took 1.971 seconds, 2.536 MiB/s AES-256-CBC-dec 5 MiB took 2.015 seconds, 2.481 MiB/s AES-128-GCM-enc 5 MiB took 10.777 seconds, 0.464 MiB/s AES-128-GCM-dec 5 MiB took 10.744 seconds, 0.465 MiB/s AES-192-GCM-enc 5 MiB took 10.983 seconds, 0.455 MiB/s AES-192-GCM-dec 5 MiB took 10.980 seconds, 0.455 MiB/s AES-256-GCM-enc 5 MiB took 11.218 seconds, 0.446 MiB/s AES-256-GCM-dec 5 MiB took 11.215 seconds, 0.446 MiB/s GMAC Table 4-bit 1024 KiB took 1.863 seconds, 549.684 KiB/s CHACHA 10 MiB took 1.483 seconds, 6.742 MiB/s CHA-POLY 5 MiB took 1.031 seconds, 4.852 MiB/s POLY1305 20 MiB took 1.158 seconds, 17.270 MiB/s SHA 10 MiB took 1.063 seconds, 9.410 MiB/s SHA-256 5 MiB took 1.494 seconds, 3.346 MiB/s SHA3-224 5 MiB took 2.609 seconds, 1.917 MiB/s SHA3-256 5 MiB took 2.757 seconds, 1.814 MiB/s SHA3-384 5 MiB took 3.578 seconds, 1.398 MiB/s SHA3-512 5 MiB took 5.126 seconds, 0.975 MiB/s HMAC-SHA 10 MiB took 1.062 seconds, 9.412 MiB/s HMAC-SHA256 5 MiB took 1.494 seconds, 3.346 MiB/s RSA 2048 public 100 ops took 1.309 sec, avg 13.094 ms, 76.373 ops/sec RSA 2048 private 100 ops took 74.411 sec, avg 744.114 ms, 1.344 ops/sec DH 2048 key gen 4 ops took 1.291 sec, avg 322.812 ms, 3.098 ops/sec DH 2048 agree 100 ops took 32.274 sec, avg 322.741 ms, 3.098 ops/sec ECC [ SECP256R1] 256 key gen 100 ops took 5.748 sec, avg 57.484 ms, 17.396 ops/sec ECDHE [ SECP256R1] 256 agree 100 ops took 5.737 sec, avg 57.371 ms, 17.431 ops/sec ECDSA [ SECP256R1] 256 sign 100 ops took 6.360 sec, avg 63.599 ms, 15.723 ops/sec ECDSA [ SECP256R1] 256 verify 100 ops took 11.532 sec, avg 115.318 ms, 8.672 ops/sec
These results underscore the potential of integrating wolfSSL’s cryptographic solutions with Gaisler’s advanced hardware, paving the way for secure high-performance cryptography that comply with latest industry standards, including DO-178C Level A, FIPS 140-3 and MISRA-C.
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
Live Webinar: Learn to Bring (D)TLS to any Transport via wolfSSL’s I/O Callbacks
Secure Bluetooth and Beyond: Bring (D)TLS to Any Transport Layer with wolfSSL’s I/O Callbacks.
Join us on July 16th at 9 AM PT for a live webinar with wolfSSL Senior Software Developer Anthony Hu, as we explore how to secure communication transport layers like Bluetooth Low Energy (BTLE), serial interfaces, and other custom or resource-constrained systems.
Register now: Learn to Bring (D)TLS to any Transport via wolfSSL’s I/O Callbacks
Date: July 16th | 9 AM PT
In this session, you’ll learn how to integrate wolfSSL’s (D)TLS stack by replacing the default send/receive functions with your own I/O callbacks. wolfSSL’s flexible I/O model gives you full control over how encrypted data is transmitted.
This webinar will cover:
- The motivation behind using I/O callbacks and how they work
- Simple examples to demonstrate key concepts
- How to implement callbacks for platform-specific and language-specific ports
- Real-world use cases, including a featured example using BTLE
Register today to learn how you can add (D)TLS to a custom communication stack.
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 call us at +1 425 245 8247.
Download wolfSSL Now
FIPS-Certified WireGuard
As WireGuard continues to grow in popularity for its simplicity and efficiency in VPN deployments, security-conscious organizations are increasingly demanding solutions that adhere to stringent security standards, such as FIPS 140-3 or CMMC 2.0. FIPS certification is a key requirement for governmental agencies and industries like defense and healthcare, where secure cryptographic implementations are mandatory and or in spaces where CMMC 2.0 compliance is a must. However, WireGuard’s default cryptographic implementations, while highly secure, are not FIPS-certified.
This is where wolfCrypt steps in. wolfCrypt is a lightweight, portable, and highly optimized cryptographic library that offers FIPS 140-3 certification, making it an ideal partner for users seeking FIPS compliance in their WireGuard deployments.
wolfCrypt FIPS integrates seamlessly with both the C and Go implementations of WireGuard, offering developers flexibility in choosing their preferred solution. For those using the C version of WireGuard, wolfCrypt can also be directly employed in kernel space via the wolfSSL kernel module.
So by leveraging our integration, users can gain access to a VPN solution that is both secure and FIPS-compliant. The performance of WireGuard, combined with the certified cryptographic operations of wolfCrypt, ensures that you don’t sacrifice speed or security. In fact, with wolfCrypt’s ability to utilize hardware acceleration, you might end up with a much faster WireGuard. Additionally, wolfCrypt’s small footprint makes it a practical choice for deployments in constrained environments, including IoT devices, embedded systems, and edge computing setups. You get a robust, certified security layer without bogging down performance.
Are you interested in WireGuard with wolfCrypt FIPS?
If you have questions about any of the above or need assistance, please contact us at facts@wolfSSL.com or call us at +1 425 245 8247.
Download wolfSSL Now
Broken Cryptographic Algorithms
wolfSSL’s wolfcrypt library includes several cryptographic algorithms that are now considered broken or deprecated. While these algorithms are typically disabled by default, developers should be aware of their security implications. Here is the list of these algorithms along with links to documents explaining why they are no longer considered secure:
- RC4/ARC4: Prohibited for TLS use due to keystream biases and practical attacks
- MD2: Moved to Historic Status due to collision attacks
- MD4: Moved to Historic Status, full collision attacks demonstrated
- MD5: Practical collision attacks, can generate collisions in seconds (See https://github.com/wolfSSL/wolfssl/pull/8895)
- SHA-1: Collision attacks demonstrated, officially retired by NIST in 2022
- DES: 56-bit key easily crackable by brute force attacks with modern hardware
- 3DES/TDEA: Deprecated by NIST, vulnerable to Sweet32 birthday attacks
- DSA: Being phased out by NIST, vulnerable to nonce reuse attacks
- RSA-1024 and weaker: There are experiments showing this is already too weak.
Note that these are still in the wolfSSL code base for some specific customer needs.
- Legacy Compatibility: Existing systems and embedded devices require these algorithms for interoperability
- Standards Compliance: Industry standards and regulatory requirements mandate support during transition periods
- Backward Compatibility: Applications migrating from legacy systems need continued support
- Gradual Migration Support: Organizations require time and pathways to transition to secure alternatives
NOTE: These algorithms are disabled by default and require explicit compilation flags (such as WOLFSSL_ALLOW_RC4) to enable them, demonstrating wolfSSL’s commitment to security best practices while maintaining necessary compatibility. There are other ways to enable some of these algorithms that you should be careful about:
- –enable-all will enable all these algorithms
- –enable-all-crypto will enable all these algorithms
- –enable-openssh will enable DSA
- –enable-wpas will enable DSA
- –enable-curl will enable DES3
- –enable-stunnel will enable DES3
- –enable-oldtls will enable MD5 and SHA-1
A great way to check if these algorithms are enabled is to inspect your wolfssl/options.h to see what macros are defined.
All that said, no matter how strong your algorithms are, if you have weak entropy or use weak parameters, your cryptography is eventually destined to fail. Another threat is quantum computers. As the state of the art improves in the field of quantum computing, so increases the risk to our currently considered secure algorithms. If you find these points confusing, please do reach out to us for guidance.
Please think very carefully before enabling any of these algorithms and please do reach out to us if you have any uncertainty with regards to whether you need them.
Here are some other algorithms that are considered broken:
- Dual_EC_DRBG: back-doored
- SIKE (Supersingular Isogeny Key Exchange): broken during NIST PQC competition
- Merkle–Hellman knapsack cryptosystem: broken by Shamir
- Caesar Cipher: vulnerable to brute force attacks and statistical analysis
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
Enhancements to wolfCLU: PKCS8, Base64, and Improved Certificate Verification
We’re excited to announce recent improvements to wolfCLU, wolfSSL’s command line tool designed to make working with cryptographic data even easier and more flexible.
PKCS8 and Base64 Support
- pkcs8: Easily parse and handle PKCS#8-formatted private keys, ensuring compatibility with modern secure key formatting standards.
- base64: Encode or decode data in Base64 format directly from the command line.
Expanded Certificate Verification with -untrusted
The verif command now supports the -untrusted option, enabling verification of certificate chains that include intermediate CAs not directly trusted by the root. This makes wolfCLU a better fit for real-world PKI use cases where trust anchors and intermediates are handled separately.
Example:
$ ./wolfssl verify -in cert.pem -CAfile root.pem -untrusted intermediate.pem
Would you like to see more feature additions to wolfCLU?
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
Migrating to wolfSSL from mbedTLS
We wanted to highlight a useful migration guide posted by Amazon for their AWS IoT Core with FreeRTOS showing how to migrate from mbedTLS to wolfSSL. The migration guide shows useful API mappings and how to expose PKCS11 capabilities.
Check out the FreeRTOS with mbedTLS to FreeRTOS with wolfSSL Migration Guide v1.0.
FreeRTOS is a real-time operating system used in many embedded systems. It is lightweight and optimized for microcontrollers and small processors. For systems using cryptography or TLS, wolfSSL is a perfect match, so we wanted to highlight a guide for migrating from mbedTLS to wolfSSL.
The AWS IoT Core is a managed cloud service for secure, reliable communication between embedded devices and the AWS Cloud. The AWS Iot Core requires TLS communication to establish connections.
Why Migrate from mbedTLS to wolfSSL?
Moving to wolfSSL offers several advantages for embedded environments, including:
- Smaller footprint and performance optimizations: wolfSSL provides a reduced memory footprint and faster cryptographic processing.
- Latest Protocols: It also includes full support for TLS 1.3 and DTLS 1.3, enabling shorter handshakes and stronger encryption.
- Professional support: Direct support from engineers who authored and maintained the code. Free pre-sales support and paid support plans available.
- Commercial licensing: While open source, wolfSSL also offers commercial licenses for proprietary projects
- FIPS 140-3 certified cryptographic software module, making it suitable for regulated industries.
- Easy integration and extensive resources: The library includes detailed documentation and examples, simplifying testing and adoption.
- Expanded algorithm support: wolfSSL includes cryptographic algorithms beyond mbedTLS’s offerings such as Post Quantum (PQ) ML-DSA, ML-KEM, XMSS and LMSS.
- Assembly optimizations for ARM Cortex-M and A. We typically see a 10x speedup using our hand crafted assembly speedups, which are available for all our commonly used symmetric and asymmetric algorithms.
Note: This migration guide is fairly dated. Since then wolfSSL has developed and maintains full PKCS11 support to either consume a PKCS11 provider or to be one through our wolfPKCS11 provider. We also support using a TPM 2.0 module as the cryptographic and storage provider for wolfPKCS11.
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
Live Webinar: The Basics of wolfBoot and All the Advanced Features We Have Recently Added
Secure your boot process with built-in post-quantum algorithms, hybrid crypto, and hardware-backed protection using wolfBoot.
Join us for the webinar, “The Basics of wolfBoot and the Advanced Features We Have Recently Added,” on July 9th at 9 AM PT. Presented by wolfSSL Senior Software Engineer Daniele Lacamera, this session introduces wolfBoot’s secure boot fundamentals and showcases new capabilities for cryptographic agility, platform expansion, and hardware trust integration.
Register Now: The Basics of wolfBoot and All the Advanced Features We Have Recently Added
Date: July 9th | 9 AM PT
wolfBoot is a lightweight, portable secure bootloader designed for embedded systems. It enables secure firmware updates, trusted execution, and cryptographic flexibility with wolfCrypt. In this webinar, you’ll learn how wolfBoot now supports post-quantum algorithms, hybrid secure boot schemes, HSM integration, and new hardware platforms that support next-generation cybersecurity requirements.
In this webinar, you’ll learn how to:
- Apply post-quantum algorithms (XMSS, LMS, ML-DSA) natively with wolfCrypt
- Combine classic and post-quantum algorithms in a hybrid secure boot implementation
- Leverage wolfHSM for secure key storage and cryptographic operations
- Deploy wolfBoot on Intel TigerLake to support x86-based platforms
- Harden Arm TrustZone-M environments with isolated cryptographic execution
Register now to strengthen your secure boot design with the latest advancements in wolfBoot.
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 call us at +1 425 245 8247.
Download wolfSSL Now
Cryptoagility
Have you heard the newest and most pervasive buzzword in online security? Recently, the most popular and over-hyped expression doing the rounds these days is “Cryptoagility”. Why do we think it is so overhyped? Because if you are simply looking for a definition, you’ll be hard pressed to find one. People who talk about it can barely define it.
Most will have you believe in a vague notion of being able to swap out algorithms in real time via the click of a mouse button. No need for reboots, updates or interference from system administrators. Some will even go as far as having the ability to swap different implementations of the same algorithms. Uber flexibility in the runtime environment.
Here at wolfSSL we have a more nuanced approach to cryptoagility. What we just described above is what we call RuntimebCryptoagility and if your system can accommodate it and you are willing to spend the resources to have it, then perhaps you might want to look into our wolfEngine and wolfProvider products.
The other kind of Cryptoagility where the wolfSSL team specializes in is Buildtime Cryptoagility. We recognize that when it comes to embedded systems, resources are at a premium and can not be wasted. With that in mind, currently unused algorithms and data are taking up valuable memory and footprint. For example, if you’re planning a post-quantum transition, having those algorithms in your firmware now might not be practical. With wolfBoot, our super efficient boot loader implementation, that migration is a simple and seamless firmware update away. When the time comes, rebuild your firmware with the algorithms required and have a seamless Cryptoagility experience.
Note that it has been this way for years. Here at wolfSSL, we didn’t need to create a new buzzword to serve our customers.
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
Coming Soon: tiny-curl for Zephyr RTOS
At wolfSSL, we’re excited to announce plans for a tiny-curl port tailored for Zephyr RTOS. This will bring lightweight HTTPS client capabilities to one of the most widely used real-time operating systems for embedded devices.
Stay tuned for updates as we work to integrate tiny-curl’s proven functionality into the Zephyr ecosystem.
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
Weekly updates
Archives
- July 2025 (11)
- June 2025 (22)
- May 2025 (25)
- April 2025 (24)
- March 2025 (22)
- February 2025 (21)
- January 2025 (23)
- December 2024 (22)
- November 2024 (29)
- October 2024 (18)
- September 2024 (21)
- August 2024 (24)
- July 2024 (27)
- June 2024 (22)
- May 2024 (28)
- April 2024 (29)
- March 2024 (21)
- February 2024 (18)
- January 2024 (21)
- December 2023 (20)
- November 2023 (20)
- October 2023 (23)
- September 2023 (17)
- August 2023 (25)
- July 2023 (39)
- June 2023 (13)
- May 2023 (11)
- April 2023 (6)
- March 2023 (23)
- February 2023 (7)
- January 2023 (7)
- December 2022 (15)
- November 2022 (11)
- October 2022 (8)
- September 2022 (7)
- August 2022 (12)
- July 2022 (7)
- June 2022 (14)
- May 2022 (10)
- April 2022 (11)
- March 2022 (12)
- February 2022 (22)
- January 2022 (12)
- December 2021 (13)
- November 2021 (27)
- October 2021 (11)
- September 2021 (14)
- August 2021 (10)
- July 2021 (16)
- June 2021 (13)
- May 2021 (9)
- April 2021 (13)
- March 2021 (24)
- February 2021 (22)
- January 2021 (18)
- December 2020 (19)
- November 2020 (11)
- October 2020 (3)
- September 2020 (20)
- August 2020 (11)
- July 2020 (7)
- June 2020 (14)
- May 2020 (13)
- April 2020 (14)
- March 2020 (4)
- February 2020 (21)
- January 2020 (18)
- December 2019 (7)
- November 2019 (16)
- October 2019 (14)
- September 2019 (18)
- August 2019 (16)
- July 2019 (8)
- June 2019 (9)
- May 2019 (28)
- April 2019 (27)
- March 2019 (15)
- February 2019 (10)
- January 2019 (16)
- December 2018 (24)
- November 2018 (9)
- October 2018 (15)
- September 2018 (15)
- August 2018 (5)
- July 2018 (15)
- June 2018 (29)
- May 2018 (12)
- April 2018 (6)
- March 2018 (18)
- February 2018 (6)
- January 2018 (11)
- December 2017 (5)
- November 2017 (12)
- October 2017 (5)
- September 2017 (7)
- August 2017 (6)
- July 2017 (11)
- June 2017 (7)
- May 2017 (9)
- April 2017 (5)
- March 2017 (6)
- January 2017 (8)
- December 2016 (2)
- November 2016 (1)
- October 2016 (15)
- September 2016 (6)
- August 2016 (5)
- July 2016 (4)
- June 2016 (9)
- May 2016 (4)
- April 2016 (4)
- March 2016 (4)
- February 2016 (9)
- January 2016 (6)
- December 2015 (4)
- November 2015 (6)
- October 2015 (5)
- September 2015 (5)
- August 2015 (8)
- July 2015 (7)
- June 2015 (9)
- May 2015 (1)
- April 2015 (4)
- March 2015 (12)
- January 2015 (4)
- December 2014 (6)
- November 2014 (3)
- October 2014 (1)
- September 2014 (11)
- August 2014 (5)
- July 2014 (9)
- June 2014 (10)
- May 2014 (5)
- April 2014 (9)
- February 2014 (3)
- January 2014 (5)
- December 2013 (7)
- November 2013 (4)
- October 2013 (7)
- September 2013 (3)
- August 2013 (9)
- July 2013 (7)
- June 2013 (4)
- May 2013 (7)
- April 2013 (4)
- March 2013 (2)
- February 2013 (3)
- January 2013 (8)
- December 2012 (12)
- November 2012 (5)
- October 2012 (7)
- September 2012 (3)
- August 2012 (6)
- July 2012 (4)
- June 2012 (3)
- May 2012 (4)
- April 2012 (6)
- March 2012 (2)
- February 2012 (5)
- January 2012 (7)
- December 2011 (5)
- November 2011 (7)
- October 2011 (5)
- September 2011 (6)
- August 2011 (5)
- July 2011 (2)
- June 2011 (7)
- May 2011 (11)
- April 2011 (4)
- March 2011 (12)
- February 2011 (7)
- January 2011 (11)
- December 2010 (17)
- November 2010 (12)
- October 2010 (11)
- September 2010 (9)
- August 2010 (20)
- July 2010 (12)
- June 2010 (7)
- May 2010 (1)
- January 2010 (2)
- November 2009 (2)
- October 2009 (1)
- September 2009 (1)
- May 2009 (1)
- February 2009 (1)
- January 2009 (1)
- December 2008 (1)