wolfSSL 5.8.2 Now Available

wolfSSL 5.8.2 is now available! We are excited to announce the release of wolfSSL 5.8.2, packed with significant enhancements, introducing new functionalities, and refining existing features!

Important Notes for this Release

  • GPLv3 Licensing: wolfSSL has transitioned from GPLv2 to GPLv3.
  • Deprecated Feature: `–enable-heapmath` is now deprecated.
  • MD5 Disabled by Default: For enhanced security, MD5 is now disabled by default.

Key Highlights of wolfSSL 5.8.2

Vulnerability Mitigations:

  • ECC and Ed25519 Fault Injection Mitigation (Low): (Thanks to Kevin from Fraunhofer AISEC)
  • Apple Native Cert Validation Override (High – CVE-2025-7395): (Thanks to Thomas Leong from ExpressVPN)
  • Predictable `RAND_bytes()` after `fork()` (Medium – CVE-2025-7394): (Thanks to Per Allansson from Appgate)
  • Curve25519 Blinding Enabled by Default (Low – CVE-2025-7396): (Thanks to Arnaud Varillon, Laurent Sauvage, and Allan Delautre from Telecom Paris)

New Features:

  • Sniffer Enhancements: Support for multiple sessions and a new `ssl_RemoveSession()` API for cleanup.
  • New ASN.1 X509 API: `wc_GetSubjectPubKeyInfoDerFromCert` for retrieving public key information.
  • PKCS#12 Improvements: `wc_PKCS12_create()` now supports PBE_AES(256|128)_CBC key and certificate encryptions.
  • PKCS#7 Decoding: Added `wc_PKCS7_DecodeEncryptedKeyPackage()` for decoding encrypted key packages.
  • Linux Kernel Module Expansion: All AES, SHA, and HMAC functionality now implemented within the Linux Kernel Module.
  • OpenSSL Compatibility Layer Additions: New APIs for X.509 extensions and RSA PSS: `i2d_PrivateKey_bio`, `BN_ucmp`, and `X509v3_get_ext_by_NID`.
  • Platform Support: Added support for STM32N6.
  • Assembly Optimizations: Implemented SHA-256 for PPC 32 assembly.

Improvements & Optimizations:

This release includes a wide range of improvements across various categories, including:

  • Extensive Linux Kernel Module (LinuxKM) Enhancements: Numerous minor fixes, registrations, and optimizations for cryptography operations within the Linux Kernel Module.
  • Post-Quantum Cryptography (PQC) & Asymmetric Algorithms: Updates to Kyber, backward compatibility for ML_KEM IDs, fixes for LMS building and parameters, and OpenSSL format support for ML-DSA/Dilithium.
  • Build System & Portability: General build configuration fixes, improvements for older GCC versions, new CMakePresets, and default MD5 disabling.
  • Testing & Debugging: Enhanced debugging output, additional unit tests for increased code coverage, and improved benchmark help options.
  • Certificates & ASN.1: Improved handling of X509 extensions, fixed printing of empty names, and better error handling.
  • TLS/DTLS & Handshake: Corrected group handling, improved DTLS record processing, and refined TLS 1.3 key derivation.
  • Memory Management & Optimizations: Stack refactors, improved stack size with MLKEM and Dilithium, and heap math improvements.
  • Cryptography & Hash Functions: Added options to disable assembly optimizations for SipHash and SHA3, and improved Aarch64 XFENCE.
  • Platform-Specific & Hardware Integration: Explicit support for ESP32P4, public `wc_tsip_*` APIs, and enhanced PlatformIO certificate bundle support.
  • General Improvements & Refactoring: Updated libspdm, fixed PEM key formatting, and improved API accessibility for certificate failure callbacks.

wolfSSL 5.8.2 also includes some nice bug fixes, addressing issues across various modules, ensuring greater stability and reliability. For a complete and detailed list of all changes, please refer to the full release notes.

We encourage all users to upgrade to wolfSSL 5.8.2 to take advantage of these important security updates, new features, and performance enhancements. Download the latest release.

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

ML-KEM Versus ML-DSA

ML-KEM (Module Lattice Key Encapsulation Mechanism) is for secure key exchange. ML-KEM enables two parties to establish a shared secret key over an insecure channel.

ML-DSA (Module Lattice Digital Signature Algorithm) is for authentication. ML-DSA allows a signer to generate a digital signature that can be verified by others, ensuring the authenticity and integrity of a message.

Both ML-KEM and ML-DSA are public key algorithms; that is to say, both have a key generation operation that generates a public key and private key.

For ML-KEM, an encapsulation operation uses the public key to generate a secret and ciphertext. The decapsulation operation uses the private key and ciphertext to get the same secret.

For ML-DSA, the private key and a message are used to generate a signature. The public key, message, and signature are used in an operation to verify that the signature of the message was generated by the corresponding private key.

The most important thing they have in common is that they are both post-quantum algorithms that have already been standardized by NIST and can be used TODAY!

In summary, ML-KEM and ML-DSA serve different purposes in cryptography, with ML-KEM focused on secure key transport and ML-DSA focused on digital signatures and authentication, but both protecting against a CRQC (Cryptographically Relevant Quantum Computer).

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

Using ECH with curl and wolfSSL

The Server Name Indication (SNI) extension to TLS allows the client to specify the name of the server it is trying to connect to, which allows the server to select between multiple virtual servers and present the appropriate certificate for the connection. The client sends the server name as a part of a Client Hello message. This Client Hello data is transmitted before encryption is set up for the connection so it can be observed by a third party.

The Encrypted Client Hello (ECH) extension to TLS 1.3 allows the inner Client Hello message that a TLS client sends to be encrypted. This inner Client Hello contains the actual server to be reached, while the outer Client Hello uses a generic public name that could be the same for many servers hosted by a company, for example. ECH is a much newer extension and currently is not deployed on most servers.

curl and wolfSSL both include support for ECH.

Install wolfSSL

First, the wolfssl library must be installed with ECH support.
Download the wolfSSL release and install with:

$ ./configure --enable-ech --enable-curl
$ make
$ sudo make instal

Install curl

Next, curl must be built with wolfSSL support. Example if wolfSSL was installed to /usr/local (the default):

$ ./configure --enable-ech --with-wolfssl=/usr/local
$ make
$ sudo make install

Enabling ECH

The –ech argument to curl can be used to enable ECH. It accepts a few different values such as false to not use ECH (the default), true to attempt ECH but fall back to not using it if not available, and hard to force using ECH and fail if the server does not support it.

Additionally, the –doh-url option should be supplied to curl to provide a DNS-over-HTTPS URL to use for DNS lookup.

Example Use

curl –ech hard –doh-url
https://one.one.one.one/dns-query
https://defo.ie/ech-check.php

This example uses –ech hard which will cause curl to fail if ECH cannot be used. In the returned payload, these lines are observed:

<p>SSL_ECH_OUTER_SNI: cover.defo.ie <br />
SSL_ECH_INNER_SNI: defo.ie <br />
SSL_ECH_STATUS: success <img src="greentick-small.png" alt="good" /> <br />
</p>

If we capture the traffic with Wireshark, we observe the following:

In this capture, we can see that the outer Client Hello message uses an unencrypted public server name (in this case “cover.defo.ie“) while the inner Client Hello containing the actual server name we’re trying to reach is encrypted.

In contrast, if we capture without ECH being enabled, we see the following:

Here we see that the entire Client Hello is unencrypted and the SNI server name can be observed as “defo.ie“.

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

Trusted by Design: How wolfSSL and Dark Sky Technology Came Together

How wolfSSL and Dark Sky Technology Secure Embedded Systems

When defense systems run open-source code touched by foreign adversaries, it’s not just risky—it’s a national security threat. That’s why wolfSSL and Dark Sky Technology teamed up: to combine certifiable cryptography with provable trust.

wolfSSL builds the most trusted cryptography on the market. Our lightweight, FIPS 140-3 validated wolfCrypt library secures everything from satellites to submarines—where performance, footprint, and reliability are non-negotiable. We support secure boot, secure firmware updates, and full (D)TLS 1.3, all engineered to meet the toughest standards like DO-178C DAL A and CNSA 2.0.

Dark Sky Technology defends America’s most critical systems from hidden threats in open-source software. Their platform, Bulletproof Trust, gives defense contractors and government agencies confidence in the integrity of their code by analyzing every risk vector:

  • Contributors (who touched it)
  • Vulnerabilities (what’s exposed)
  • Licenses (what’s legal)
  • Maintainability, code quality, and hygiene (what’s operationally dangerous)

Why We Partnered

Trust needs proof. Dark Sky independently evaluated wolfSSL using their TrustScore engine. Results:

  • 0 sanctioned contributors
  • No license conflicts or IP landmines
  • Clean, maintainable code
  • No embedded secrets or repo risk

You can view our TrustScore and full transparency report here: Dark Sky TrustScore for wolfSSL.

Why It Matters

For defense, software trust is mandatory. You must know what your code does—and who touched it.

wolfSSL delivers certifiable crypto.
Dark Sky proves its provenance.

No guesswork. No compromise. Just trusted software—by design.

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.

  1. Legacy Compatibility: Existing systems and embedded devices require these algorithms for interoperability
  2. Standards Compliance: Industry standards and regulatory requirements mandate support during transition periods
  3. Backward Compatibility: Applications migrating from legacy systems need continued support
  4. 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:

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

Posts navigation

1 2