Open Source Project Ports: Socat

Thanks to the portability of our wolfCrypt library, plus our team of expert engineers, wolfSSL is frequently adding new ports. Keep an eye out as we continue showcasing a few of the latest open source project ports over the next few weeks!

We have recently integrated wolfSSL with the socat tool for Linux. This port allows for the use of socat with our FIPS-validated crypto library, wolfCrypt. Socat is a command line based utility that allows for bidirectional data transfers between two independent channels. For more information on socat, please visit the project’s website at

As of wolfSSL version 4.8.0, we have enabled socat to be able to call into wolfSSL through the OpenSSL compatibility layer. You can access the GitHub page here:

Need more? Subscribe to our YouTube channel for access to wolfSSL webinars!
Love it? Star us on GitHub!

Post-Quantum wolfSSH

The wolfSSL library is now safe against the “Harvest Now, Decrypt Later” post-quantum threat model with the addition of our new TLS 1.3 post-quantum groups. But where does that leave wolfSSH? It is still only using RSA and elliptic curve key exchange algorithms which are vulnerable to the threat model mentioned above. If you are interested in knowing about our plans to protect wolfSSH using post-quantum key exchanges, please get in contact with us at

Upcoming Live Webinar : wolfEngine – wolfCrypt as an Engine for OpenSSL

Join our live wolfEngine  webinar, where we introduce one of our newest products wolfEngine, a separate standalone library which links against wolfSSL (libwolfssl) and OpenSSL. wolfEngine implements and exposes an OpenSSL engine implementation which wraps the wolfCrypt native API internally. Algorithm support matches that as listed on the wolfCrypt FIPS 140-2 certificate #3389.

Learn about about what wolfEngine is, why you should care, and why wolfEngine could be the solution to all of your problems. As always bring your questions for the Q&A following the presentation.

wolfEngine : wolfCrypt as an Engine for OpenSSL
Time: Oct 7, 2021 09:00 AM in Pacific Time
Register here:

If you have any other questions or concerns please reach out to or anytime.

Loading wolfSSL into the Linux Kernel – Update

wolfSSL Linux kernel module support has grown by leaps and bounds, with new support for public key (PK) cryptographic acceleration, FIPS 140-3, accelerated crypto in IRQ handlers, portability improvements, and overall feature completeness.

The module provides the entire libwolfssl API natively to other kernel modules, allowing fully kernel-resident TLS/DTLS endpoints with in-kernel handshaking.  Configuration and building is turnkey via the --enable-linuxkm option, and can optionally be configured for cryptographic self-test at load time (POST), including full FIPS 140-3 core hash integrity verification and self-test.

As with library builds, the kernel module can be configured in detail to meet application requirements, while staying within target capabilities and limitations.  In particular, developers can opt to link in only the wolfCrypt suite of low level cryptographic algorithms, or can include the full TLS protocol stack with TLS 1.3 support.

For PK operations, the kernel module leverages our new function-complete SP bignum implementation, featuring state of the art performance and side channel attack immunity.  AVX2 and AES-NI accelerations are available on x86, and are usable from both normal kernel threads and from interrupt handler contexts. When configured for AES-NI acceleration, the module delivers AES256-GCM encrypt/decrypt at better than 1 byte per cycle.

Kernel module builds of libwolfssl are supported in wolfSSL release 4.6 and newer, and are available in our mainline github repository, supporting the 3.x, 4.x, and 5.x Linux version lines on x86-64, with limited support for ARM and MIPS. Full FIPS 140-3 support on x86-64 will be available in the forthcoming wolfSSL Version 5.0 release.

Need more? Subscribe to our YouTube channel for access to wolfSSL webinars!
Love it? Star us on GitHub!

wolfSSL not affected by CVE-2021-3711, nor CVE-2021-3712

It came to our attention that OpenSSL just published two new vulnerabilities.

  • CVE-2021-3711 – “SM2 decryption buffer overflow” (nakedsecurity)
  • CVE-202103712 – “Read buffer overruns processing ASN.1 strings.” (nakedsecurity)

These were specific OpenSSL issues and do not affect wolfSSL. For a list of CVEs that apply to wolfSSL please watch the security page on our website here:

We wanted to take this opportunity to remind our customers and users that wolfSSL is in no way related to OpenSSL. wolfSSL was written from the ground up and is a unique SSL/TLS implementation.

That being said, wolfSSL does support an OpenSSL compatibility layer allowing OpenSSL users to drop in wolfSSL but continue to use the most commonly found OpenSSL API’s after re-compiling their applications to link against wolfSSL.

One individual also pointed out the time delta between report and fix on the above CVEs and wolfSSL would like to remind our customers and users of how proud we are of our less than 48 hour delta between report and fix. For more on our response time and process regarding vulnerabilities check out

If you have any other questions or concerns please reach out to or anytime.


Posts navigation

1 2