“Get Up to Speed with WolfSSL in 2023: Join Our Webinar Series”

Happy New Year! As we kick off 2023, wolfSSL is excited to announce a series of webinars to help you get started with our software.

First up is our webinar on January 5th at 10 AM (PST) on getting started with the wolfSSL TLS library. This webinar will cover a range of topics including an overview of TLS 1.3, how to build and use the wolfSSL library, and tips on debugging. There will also be a Q&A session to answer any questions you may have. Register here: https://us02web.zoom.us/webinar/register/WN_bkptS_9fRF2W1aV-zGFjsg

On January 19th, join wolfSSL engineer Eric Blankenhorn for a webinar on our wolfMQTT library. This multi-platform, space-conscious and extensible library is a client implementation of MQTT written in C for embedded use, and supports SSL/TLS via the wolfSSL library. Bring your questions for the Q&A session to follow. Register here: https://us02web.zoom.us/webinar/register/WN_iep1f_sfQq6NDEo6irQANQ

Finally, on January 26th, we’ll be hosting a webinar on getting started with wolfSSH, a lightweight SSHv2 client and server library. This webinar will cover topics such as the wolfSSH package structure, how to build and use the library, and debugging tips. As always, there will be a Q&A session to answer any questions you may have. Register here: https://us02web.zoom.us/webinar/register/WN_kaAs6wWTS7Ct2FXo6pr5oA

We hope to see you at one or all of these webinars!

Heard of NuttX?

Heard of NuttX?  Fresh out of the Apache incubator, it’s a small RTOS with a focus on POSIX and ANSI standards compliance, scales from 8 to 64-bit microcontrollers, is extensively documented, ported to many platforms, and is very easy to get started with

 Here at wolfSSL we are hard at work testing wolfSSL with NuttX.  The flexible, efficient nature of NuttX makes it a natural fit for a lean, embedded SSL/TLS implementation like wolfSSL.  

Interested?  Let us know!

For questions please email facts@wolfssl.com

wolfSSH v1.4.12 Release

wolfSSL are proud to announce a new incremental update to wolfSSH: v1.4.12!

In this release, we have wolfSSHD running. It seamlessly fits in where other SSHDs are, and is able to parse and make use of existing sshd_config files that are in place.

We are also proud to announce that wolfSSH builds and runs in the Green Hills Software INTEGRITY environment. It takes advantage of INTEGRITY’s POSIX API. You can run a shell through it, or upload files to the local filesystem using SFTP.

For the cutting edge, wolfSSH adds Hybrid ECDH-P256 Kyber-Level1 for post-quantum hybrid key exchange.

The release information from the change log is reposted below:

New Feature Additions and Improvements

  • Support for Green Hills Software's INTEGRITY
  • wolfSSHd Release (https://github.com/wolfSSL/wolfssh/pull/453 rounds off testing and additions)
  • Support for RFC 6187, using X.509 Certificates as public keys
  • OCSP and CRL checking for X.509 Certificates (uses wolfSSL CertManager)
  • Add callback to the server for reporting userauth result
  • FPKI profile checking support
  • chroot jailing for SFTP in wolfSSHd
  • Permission level changes in wolfSSHd
  • Add Hybrid ECDH-P256 Kyber-Level1
  • Multiple server keys
  • Makefile updates
  • Remove dependency on wolfSSL being built with public math enabled


  • Fixes for compiler complaints using GHS compiler
  • Fixes for compiler complaints using GCC 4.0.2
  • Fixes for the directory path cleanup function for SFTP
  • Fixes for SFTP directory listing when on Windows
  • Fixes for large file transfers with SFTP
  • Fixes for port forwarding
  • Fix for building with QNX
  • Fix for the wolfSSHd grace time alarm
  • Fixes for Yocto builds
  • Fixes for issues found with fuzzing


  • The vulnerability fixed in wolfSSH v1.4.8 finally issued CVE-2022-32073

For any questions about using wolfSSH contact us at facts@wolfssl.com

wolfSSL 5.5.4 Release!

Merry Christmas! The Christmas release of wolfSSL is here, version 5.5.4! This includes some minor feature additions, QUIC related changes for HAProxy use, port to the MAXQ hardware, improvements in performance, as well as additional enhancements and fixes. In this development cycle we also did testing of using wolfSSL with NuttX, and wolfSSL is ready to go for any projects looking for TLS / cryptography with NuttX.

Here are some of the key new features  we added to this new version.

New Feature Additions

  •  QUIC related changes for HAProxy integration and config option
  •  Support for Analog Devices MAXQ1080 and MAXQ1065
  •  Testing and build of wolfSSL with NuttX
  •  New software based entropy gatherer with configure option --enable-entropy-memuse
  •  NXP SE050 feature expansion and fixes, adding in RSA support and conditional compile of AES and CMAC
  •  Support for multi-threaded sniffer

The full list of changes can be found in the ChangeLog.md bundled with wolfSSL or on the website www.wolfssl.com.

Visit our download page or https://github.com/wolfssl for downloading the bundle. Email us at facts@wolfssl.com with any questions.

HPKE support in wolfCrypt

HPKE support in wolfCrypt

HPKE (Hybrid Public Key Encryption) is a key encapsulation and encryption standard that allows two parties to derive a common secret and encrypt/decrypt messages using that common secret (https://www.ietf.org/archive/id/draft-irtf-cfrg-hpke-12.txt)

 HPKE has three steps in single-shot mode: 

  1. Key encapsulation (KEM) - ECC P256, P384, P521 or X25519
  2. Hash based Key Derivation (HKDF) - SHA2-256, SHA2-384, SHA2-512
  3. Authenticated Encryption with Associated Data (AEAD). AES-GCM 128/256 bit

Here is an example of how HPKE is used: https://gist.github.com/jpbland1/b2a1c46bc934fd8ee0dc4d148a8b9eab

The `Hpke` struct is used for the HPKE operations and we initialize it with our KEM, KDF and AEAD algorithms using `wc_HpkeInit`. Here we're using X25519, SHA256 and AES128. Then we need to generate keypairs to use, with the `ephemeralKey` being used by the client to seal messages and the `receiverKey` being used by the server to open them. They're both generated using `wc_HpkeGenerateKeyPair` and have a type of `void*` because they can actually be one of many types depending on the KEM algorithm chosen, which wolfCrypt takes care of internally. The client then seals our message using `wc_HpkeSealBase` which takes the client’s private key, the server’s public key, an optional info field, an optional AAD field, the message to encrypt `start_text` and the buffer to put the encrypted message into `ciphertext`. NOTE that `ciphertext` MUST be 16 bytes longer than the message we're trying to encrypt to store the AEAD tag needed to decrypt it. `wc_HpkeSerializePublicKey` will serialize an HPKE public key into a bytestring so it can be shared with the other party. Keys can later be deserialized using `wc_HpkeDeserializePublicKey`. These functions should be used to share the KEM public keys between client and server. Then for the server to decrypt, `wc_HpkeOpenBase` takes the `receiverKey`, the serialized public `ephemeralKey`, an optional info field, an optional AAD field, the ciphertext and tag to decrypt and the buffer to store the decrypted message. When finished the `plaintext` buffer will have the same data in it as the original `start_text` buffer. To free the keys when we're done using them we call `wc_HpkeFreeKey` with the `kem` and key.

Support for ECH and HPKE was added in PR https://github.com/wolfSSL/wolfssl/pull/5623

For questions please email facts@wolfssl.com

Encrypted Client Hello (ECH) now supported in wolfSSL

ECH (Encrypted Client Hello) is a draft extension for TLS 1.3 that enables a client to encrypt its client_hello in the TLS handshake to prevent leaking sensitive metadata that is sent in the clear during the normal TLS handshake. ECH was originally proposed as ESNI (Encrypted Server Name Indication), since the server name indication is one of the sensitive fields that is visible to a passive observer during the handshake, but was later renamed since it covers the entire Client Hello. ECH uses HPKE (Hybrid Public Key Encryption) to derive a shared secret and encrypt the client_hello.

ECH works by making an inner Client Hello and an outer Client Hello. The outer hello has all sensitive metadata removed and includes a new TLS extension called ECH. The inner hello contains all the sensitive information and is encrypted using HPKE and then placed into the outer hello as the ECH extension. The client sends the outer hello and the server picks up on the use of ECH and decrypts the inner hello using its HPKE key.

Here is an example of how ECH is used:


In this example we connect to the Cloudflare server that has been setup to test different TLS and security settings and then call `wolfSSL_GetEchConfigs` to get the `retry_configs`. We then make a new SSL object, call `wolfSSL_SetEchConfigs` to apply the retry configs and then connect using ECH. We do this connect and reconnect process to get the `retry_configs` by sending what's called a GREASE ECH or a dummy ECH which is sent out in the absence of a set ECH. We can skip this step if we retrieve the ECH configs from a website's DNS records, but DNS is out of the scope of this example. Once we have the ECH configs set we can connect to and use the ssl connection like normal, here we send an http request to `/cdn-cgi/trace/ HTTP/1.1\r\n`, which will send us back information about our TLS connection. In the response that prints we will see `sni=encrypted`, which means that ECH is working.

Support for ECH was added in PR https://github.com/wolfSSL/wolfssl/pull/5623

For questions please email facts@wolfssl.com

wolfSSL on Softcore RISC-V

In our never-ending quest to have wolfSSL supported and running on all platforms, everywhere, for everyone, we are proud to announce we are now supporting Softcore RISC-V Environments.

What is a Softcore RISC-V CPU? We’re glad you asked! Softcore means the electronics are created on a “soft” and reusable FPGA instead of the one-time, hard silicon manufacturing process. The RISC-V is of course open source; This allows anyone to build their own CPU and not pay any license fees for architecture or buy expensive proprietary development software. Silicon fabrication is expensive and time consuming for hardcore CPUs. 

Open-source toolchains such as those at YosysHQ allow literally anyone with a modern computer to build nearly anything imaginable on the “soft” fabric of an FPGA. This includes a full-blown CPU!  Anyone from the hobbyist building a CPU literally at the kitchen table at home to the most skilled development engineers developing next-generation, state-of-the-art custom CPUs in secret labs can use RISC-V technology. We’re there with you to help secure your data and connections to the outside world.

There are several different open-source RISC-V CPU projects out there. The one we’ve chosen to test with our wolfSSL code targets the Lattice Semiconductor ECP5-85F chip, specifically the FPGA on the Radiona ULX3S from our friends over at Crowd Supply. The soft RISC-V CPU is the Wren6991/Hazard3. This project was chosen as a test environment due to its relative grace and simplicity, as well as including a soft JTAG.

Are you interested in building your own custom CPU with wolfSSL? Contact us to see how we can help:  facts@wolfssl.com

Using user_settings.h with wolfSSL

wolfSSL has various examples of user_settings.h files that you could use to configure your build.

For users who can’t make use of Autotools, want to build with a custom IDE, or would like to track and manage their wolfSSL build configuration in a header file, we recommend the use of a custom user_settings.h header file. If WOLFSSL_USER_SETTINGS is defined when compiling the wolfSSL source files, wolfSSL will automatically include a custom header file called user_settings.h. With Autotools, --enable-usersettings can also be used with the configure command to define WOLFSSL_USER_SETTINGS. The header should be created by the user and placed on the include path. This allows users to maintain one single file for their wolfSSL build.

Some example user_settings.h files can be found in the wolfSSL repo here https://github.com/wolfSSL/wolfssl/tree/master/examples/configs. They are listed below.

  • user_settings_template.h: Template that allows modular algorithm and feature selection using #if 0 logic.
  • user_settings_all.h: This is wolfSSL with all features enabled. Equivalent to ./configure --enable-all.
  • user_settings_min_ecc.h: This is ECC and SHA-256 only. For ECC verify only add BUILD_VERIFY_ONLY.
  • user_settings_wolfboot_keytools.h: This is from wolfBoot tools/keytools and is ECC, RSA, ED25519, and ChaCha20.
  • user_settings_fipsv2.h: The FIPS v2 (3389) 140-2 certificate build options.
  • user_settings_fipsv5.h: The FIPS v5 (ready) 140-3 build options. Equivalent to ./configure --enable-fips=v5-dev.
  • user_settings_stm32.h: Example configuration file generated from the wolfSSL STM32 Cube pack.

To use these example configurations:

  1. Copy to your local project and rename to user_settings.h.
  2. Add pre-processor macro WOLFSSL_USER_SETTINGS to your project.
  3. Make sure and include #include <wolfssl/wolfcrypt/settings.h> prior to any other wolfSSL headers in your application.

Do you need any guidance configuring your wolfSSL build? Contact support@wolfssl.com to get some help from our engineers. The wolfSSL embedded SSL/TLS library supports up to TLS 1.3 and DTLS 1.3, and offers certified versions of wolfCrypt for FIPS 140-2 and DO-178C.

Rocky Linux FIPS

Are you interested in utilizing FIPS 140-2 cryptography on the Rocky Linux™ platform?  wolfSSL will soon be adding the Rocky Linux Operating Environment to our wolfCrypt FIPS certificate.  Let us know your exact hardware to ensure we add the configuration you need.  The wolfCrypt FIPS module can be used with wolfSSL, wolfSSH, third party Open Source projects like nginx and curl, and even as an OpenSSL engine.
For questions about wolfSSL or FIPS 140-2 contact facts@wolfssl.com

wolfSSL Summer of Security Internship Program 2024

Are you a college or university student interested in application, device, and Internet security?  Do you want to learn about cryptography and the implementation and application of Internet protocols (SSL/TLS, SSH, MQTT, TPM)?  If so, consider applying for wolfSSL’s 2024 Summer of Security internship program!

wolfSSL is the leading global producer of Open Source Internet security products, securing over 2 Billion active connections on the Internet today. The wolfSSL “Summer of Security” program is an internship which spans the Summer months (typically June – August, depending on class schedules) and brings qualified students on-board to learn about how security software is written, tested, and applied to real-world use cases.

Minimum Requirements

  • Currently pursuing a Bachelor’s or higher degree in Computer Science, Computer Engineering, or a related technical field.
  • Experience and familiarity with C programming
  • Experience and familiarity with git/GitHub

Prior experience with embedded systems, network programming, or Linux/Unix are a plus, but not a hard requirement for application.


The 2024 internship will be held at wolfSSL’s Bozeman, MT office.

About the Job

Interns who participate in this program gain valuable knowledge in the SSL/TLS and security industry as well as C programming experience on Linux and embedded systems.  Throughout the summer, interns play a role in improving wolfSSL products – working on testing, documentation, examples, porting, marketing, and interacting with our community.

This program is a great opportunity to be part of the Open Source community, learn how real-world software is created and maintained, gain work experience in the field of Computer Science, and work towards a potential career with the wolfSSL team.

Apply Today!

If you are interested in learning more about the wolfSSL Summer of Security internship program, please send the following items to internships@wolfssl.com:

  1. Resume with Cover Letter
  2. C Programming Sample
    • A C application which best demonstrates your C programming ability.  There are no requirements on the category or length of the application. Applications which can be compiled and run by wolfSSL recruiters are preferred.
  3. Technical Writing Sample
    • A writing sample which best demonstrates your writing ability.  There is no requirement of topic or length of this sample.

Learn More

wolfSSL Homepage
wolfSSL Products Page
wolfSSL User Manual
TLS 1.3 Support!
wolfSSL Examples Repository (GitHub)

Posts navigation

1 2