RECENT BLOG NEWS

So, what’s new at wolfSSL? Take a look below to check out the most recent news, or sign up to receive weekly email notifications containing the latest news from wolfSSL. wolfSSL also has a support-specific blog page dedicated to answering some of the more commonly received support 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

If you have any questions or run into any issues, contact us at facts@wolfssl.com, or call us at +1 425 245 8247.

 

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:

https://gist.github.com/jpbland1/ad46617fcc40934b252ce031c7aa5969

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

If you have any questions or run into any issues, contact us at facts@wolfssl.com, or call us at +1 425 245 8247.

 

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? If you have any questions or run into any issues, contact us at facts@wolfssl.com, or call us at +1 425 245 8247.

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? If you have any questions or run into any issues, contact us at facts@wolfssl.com, or call us at +1 425 245 8247. 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.

If you have any questions or run into any issues, contact us at facts@wolfssl.com, or call us at +1 425 245 8247.

 

wolfSSL Summer of Security Internship Program 2025

Are you a college or university student interested in Internet security?  Do you want to learn about cryptography and the implementation and application of Internet protocols (SSL/TLS, SSH, MQTT, TPM)?  If so, apply for wolfSSL’s 2025 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 proficiency with C programming
  • Experience and proficiency with git/GitHub
  • Experience and proficiency with Linux/Unix
  • Prior experience with embedded systems / microcontrollers, network programming, or using common security protocols (TLS, SSH, etc) are a plus, but not a hard requirement for application.

Location

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

About the Job

Interns who participate in this program gain valuable knowledge in SSL/TLS and the 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 the wolfSSL community.

This program is a great opportunity to be part of a Open Source project, 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 and 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. Sample applications should be able to be compiled and run by wolfSSL recruiters.
  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)

If you have any questions or run into any issues, contact us at facts@wolfssl.com, or call us at +1 425 245 8247.

DHE Vulnerability of CVE 2022-40735

Customers have asked about CVE 2022-40735 (https://nvd.nist.gov/vuln/detail/CVE-2022-40735) and whether they are vulnerable as users of wolfSSL. The short is answer is: No. But, there are ways that you can put yourself at risk. Let’s delve into the CVE and how best to protect yourself from attacks like this.

First of all, a description of the CVE is in order to be able to have a proper discussion. The attack centres on the use of DHE in a protocol like TLS where the server uses a large private or large parameters. The actual attack is not clear as we haven’t seen the corresponding paper at time of writing. Despite a minimal description, we can make some good security decisions to protect ourselves.

The attack has a client sending one or more messages to the server to initiate a DHE key exchange. In TLS 1.2, this means the client starts a handshake and negotiates a DHE cipher suite. In TLS 1.3, the client sends a DH key share and only lists support for DH named groups (not named curves). The attack come from the client having to do very little work while the server needs to generate a key pair.

In TLS 1.2, the server generates a key pair first and sends the DH parameters and public key to the client. The client at this point can drop the connection and start again. In TLS 1.3 the client can send the same key share over and over again and drop the connection when the server sends its public DH key.

The amount of work the server has to perform for DHE can be quite large. DHE operations are known to be quite slow and there are ways it can be even slower.

Generating a key pair for the exchange involves generating a random private key and calculating a public key. A private key can be as big as the order - the number of distinct values that can be reached by exponentiating the generator (g). The order is about the same size as the prime modulus.

Wisdom past was that you generate a private key large enough to cover the order. But this is a waste! A 2048-bit DH key has only 112 bits of security. Given that it is very hard computationally to find private key from public key, it turns out 224-bits of private key will suffice. Modular exponentiation with a 2048-bit exponent (private key) will be about 8 times slower than with a 224-bit exponent!

wolfSSL will use a small, but secure, private key when the order is not known and when using named groups.

The CVE describes the attack as a Denial of Service (DoS). That is, the server is too busy generating DH keys to do anything else. But how powerful is the server? How many connections can it handle concurrently? These are questions that you should answer based on your setup.

If a server thread is only expected to handle tens of connections a seconds and the number of DHE operations per second is significantly more, then there is no issue! But if the number of DHE operations per second is close to the required number of connections then some changes need to be made.

Another part of the attack is forcing the server to use larger parameters. For reasons of enhanced security, a server may configured to be able to use the named groups of 2048, 3072 and 4096 bits. On a modern Intel x64 server, say, 4000 2048-bit DHE key generations can be completed in a second. But for 3072-bit DHE only 2000 and for 4096-bit key generations only 1000. Therefore understanding how many connections you want to support compared to how many DHE operations that can be performed per second is important.

So using appropriate sized parameters is an important mitigation if you are to use DHE cipher suites with TLS. Ensure the server is only configured to support parameters of a size that you can handle.

An alternative mitigation is to not use DHE in your TLS handshakes. ECDHE is quite commonly supported and popular. Using X25519 can be 5 times faster than 2048-bit DHE.

There are other mitigations that involve detecting and protecting against DoS attacks. One mechanism is to detect malicious clients and block them or time them out. These protections are considered best practice and should be implemented even when not protecting against this CVE.

In summary, wolfSSL is not vulnerable to the issue of long private keys in DHE key generation as described in CVE 2022-40735. Consider carefully, though, the size of the DHE parameters you allow on you server. The relative performance of DHE operations to connection requirements may mean you should be switching to ECDHE anyway.

If you have any questions or run into any issues, contact us at facts@wolfssl.com, or call us at +1 425 245 8247.

Benchmarks for Kyber Level 1 PQM4 Integration on STM32 ARM Cortex-M4

Recently the PQM4 project fixed a bug that was preventing us from turning on optimizations. Please see https://github.com/mupq/pqm4/issues/229 . Naturally, this means we can run benchmarks now!  You can see the results on our benchmarking page at https://www.wolfssl.com/docs/benchmarks/#pq_kyber_kem_l1_pqm4_on_stm32. Here is an abbreviated and reformatted version of our results. We want to compare Kyber Level 1 against ECDSA over the SECP256R1 curve:

ECDHE [SECP256R1]  256 key gen 118 ops took 1.016 sec, avg  8.610 ms, 116.142 ops/sec

ECDHE [SECP256R1]  256 agree    56 ops took 1.016 sec, avg 18.143 ms, 55.118  ops/sec

Kyber_level1-kg                219 ops took 1.000 sec, avg  4.566 ms, 219.000 ops/sec

Kyber_level1-ed                 96 ops took 1.012 sec, avg 10.542 ms, 94.862  ops/sec

Note that Kyber does very well in that keygen on average takes 4.566 ms and an encapsulation and decapsulation cycle takes 10.542 ms which gives a total processing time to achieve a shared secret as 15.108 ms. For ECDHE a similar calculation yields 26.753 ms.  So it would seem that Kyber is marginally faster.  However, ECDHE is a NIKE (Non-Interactive Key Exchange) while Kyber is a KEM so in the context of TLS 1.3, these numbers can be somewhat misleading.

For KEMs, only the client does key generation and sends the public key to the server.  Then only the server does the encapsulation operation and sends the ciphertext back to the client. Then only the client does the decapsulation operation.

For NIKEs, both the server and the client must do the key generation operation.  Then both the server and the client must also do the key agreement step.  Since there are double the number of operations to achieve a shared secret, for a fair comparison, we need to double the average time for ECDHE.  

This gives us 15.108 ms versus 53.506 ms for Kyber and ECDHE respectively.  This makes Kyber the clear winner in processing time. That said, since Kyber has considerably larger artifacts than ECDHE, depending on your method of transmission, this margin can easily be lost if your transmission speeds are slow. 

Want benchmarks for Kyber at levels 3 and 5? What about Kyber hybridized with the NIST curves? Let us know and we’d be happy to help! If you have any questions or run into any issues, contact us at facts@wolfssl.com, or call us at +1 425 245 8247.

 

wolfSSH on Green Hills INTEGRITY RTOS

wolfSSH now runs on Green Hills Software's INTEGRITY RTOS. Rejoice! wolfSSH will build and run almost out of the box. You will have to do a little integration work to get INTEGRITY to start the server appropriately, but at that point it plays nice with the shell application and allows for SFTP. Users can log in using password or public key authentication. Because Green Hills' compiler is more strict about certain code constructs, wolfSSH has been updated to build cleanly without warnings. We look to make wolfSSH the most portable SSH solution for any platform, even bare metal. wolfSSH takes advantage of AEAD ciphers like AES-GCM and maintains a small code size.

 

wolfSSH is lovingly crafted by wolfSSL Inc in the Pacific Northwest.

If you have any questions or run into any issues, contact us at facts@wolfssl.com, or call us at +1 425 245 8247.

 

wolfSSL Support for NXP SE050 with SCP03

wolfSSL has supported the NXP SE050 since wolfSSL 5.0.0 (November 1, 2021), giving wolfSSL and wolfCrypt users the ability to use cryptography and secure key generation/storage inside the SE050 while using wolfSSL’s own APIs from the application level. We recently made some substantial additions and enhancements to wolfSSL’s SE050 support, including the following.  These are currently in our master branch on GitHub, and will be included in the next stable release of wolfSSL.

  • SE050 RSA support (sign/verify/encrypt/decrypt, PKCS#1v1.5/PSS/OAEP padding, up to 4096-bit)
  • Allowing use of larger key IDs, fully utilizing SE050’s key ID range
  • Ability to get or set SE050 key IDs to/from wolfCrypt RsaKey or ecc_key structures
  • New APIs to store and get binary objects from SE050
  • New API to erase SE050 objects at a specified key ID
  • New API to get the object size at a specified key ID
  • New define WOLFSSL_SE050_NO_TRNG to fall back to usage of /dev/random and /dev/urandom instead of SE050 TRNG
  • Additional documentation (README_SE050.md)
  • Install se050_port.h with make install for public API use on Linux hosts
  • Fix default library and include paths with “--with-se050” configure option
  • Fix for ECC P-521 where curve size can be larger than SHA-512 digest size
  • Fixes to SE050 message digest support
  • Fixes for wolfCrypt test compatibility with SE050 enabled

wolfSSL SE050 Examples

To help users get going easier and more quickly, we have published example applications designed to be integrated into the SE05x Middleware on Linux (tested on Raspbian with a Raspberry Pi). This examples are located in our wolfssl-examples repository on GitHub, along with documentation on how to integrate and build. Examples include:

  • wolfCrypt test application
  • wolfCrypt benchmark application
  • wolfCrypt SE050 key and certificate insertion and use
  • wolfCrypt CSR generation

wolfSSL HostCrypto support for SCP03 Authentication

wolfSSL can be used on the host side (HostCrypto) for secure SCP03 (Secure Channel Protocol ’03’) authentication, in place of either OpenSSL or mbedTLS. To make this possible, wolfSSL has written a HostCrypto layer that can be applied as a patch to the NXP SE05x Middleware.  Using wolfSSL HostCrypto will use wolfSSL’s software cryptography on the host side to establish the SCP03 channel.  After secure channel establishment, wolfSSL can then be used while offloading crypto and key operations to the SE050.

A patch for the SE05x Middleware for adding wolfSSL HostCrypto support can be found in our osp repository (Open Source Ports) on GitHub, along with documentation on how to patch and build on a Raspberry Pi / Raspbian environment.

Support and More Details

For more details on wolfSSL’s SE050 support, or if you have any questions or run into any issues, contact us at facts@wolfssl.com, or call us at +1 425 245 8247.

Posts navigation

1 2 3 … 52 53 54 55 56 57 58 … 195 196 197

Weekly updates

Archives