Changes In wolfSSL for ARM Thumb-2 Builds

With wolfSSL release 5.7.4 we added the macro WOLFSSL_ARMASM_THUMB2. This macro can be defined to enable Thumb-2 ARM instruction optimizations and replaces the previous attempted autodetect on the macros __arm__ and __thumb__. Giving users complete control over which ARM assembly optimizations are compiled and used.

When building for Thumb-2 the source files beginning with thumb2-* should additionally be compiled in. If WOLFSSL_ARMASM_THUMB2 is not used then the armv8-32-* files will be used. These files are located in wolfcrypt/src/port/arm/.

The benefit of now having WOLFSSL_ARMASM_THUMB2 is that users can place all files in wolfcrypt/src/port/arm/ to be compiled and use the macro gate for selecting if the Thumb-2 section is optionally compiled or ARM32 implementation is. The armv8-32- code is very similar to the thumb2- code, but Thumb-2 is smaller in size.

For assistance with ARM optimization builds contact us at support@wolfSSL.com.

If you have questions about any of the above, please contact us at facts@wolfSSL.com or +1 425 245 8247.

Download wolfSSL Now

Switching to wolfCrypt’s Implementations of Post-Quantum Algorithms

Have you been trying out post-quantum algorithms in wolfSSL’s products? As you probably know, here at wolfSSL we have a step-wise approach to post-quantum algorithm integration:

  1. Define an API in wolfCrypt.
  2. Do an integration with an existing reference implementation (ie.: liboqs, PQM4, hash-sigs liblms, xmss-reference).
  3. Use these APIs in higher level libraries and products (ie.: wolfssl, wolfssh, wolfmqtt, wolfboot) to implement features.
  4. Invest the time and effort to write and optimize our own production grade implementation of the algorithm.

For LMS, XMSS, ML-KEM and ML-DSA the time has finally come to switch to using wolfSSL’s implementations of these algorithms. It’s very simple to do so. If you are using any of the following configure-time flags simply remove them from your configure command-line:

--with-liblms
--with-libxmms
--with-liboqs

Then ensure you are enabling the relevant algorithm that you are interested in. Relevant flags are:

--enable-xmss
--enable-lms
--enable-dilithium
--enable-kyber

Once this is done, you will be using our professionally optimized and tested implementations of post-quantum algorithms.

If you have questions about any of the above, please contact us at facts@wolfSSL.com or +1 425 245 8247.

Download wolfSSL Now

Do you need post quantum versions of Apache, NGINX, Lighttpd, cURL, or stunnel?

Our wolfSSL library has several post-quantum algorithms built in, but on their own, they aren’t always useful. How else can the PQC algorithms be used in production? Well, one of our areas of expertise is getting other open-source projects working with wolfSSL and then getting those integrations using post-quantum algorithms. We have post-quantum integrations with multiple web servers, a web client, and a secure tunneling solution. Read on to learn more!

For a more heavy-duty and reliable web server with professional production-ready code, we have a post-quantum integration with Apache.

For a lighter-weight yet fully featured and dependable alternative, you can turn to our post-quantum enabled Nginx integration.

Our wolfSSL library excels in constrained environments as does Lighttpd. For the most bare bones environments, our lighttpd post-quantum integration is likely the right choice.

And for the client side, we have also made the cURL web client quantum-safe! See this video for instructions on how to build.

If you’ve got an application where making changes is difficult due to legacy software, we’ve got our post-quantum integration with stunnel to make your migration a breeze.

Go ahead and try out these open source integrations! We are eager for your feedback, and happy to support your efforts Whether it be as part of a hackathon or as an experiment to understand feasibility or to gather benchmarking data, trying out these integrations is a great step in your plan for migration to post-quantum algorithms.

If you have questions about any of the above, please contact us at facts@wolfSSL.com or +1 425 245 8247.

Download wolfSSL Now

MAX32666 and MAX32665 Hardware Acceleration added to wolfSSL

wolfSSL now supports using the Trust Protection Unit (TPU), Modular Arithmetic Accelerator (MAA), and TRNG provided by Analog Devices MAX32666 and MAX32665 microcontrollers.

The implementation can be seen in PR #7777 to wolfSSL, and is in wolfSSL starting at 5.7.4!

The port offers various usage options: fully leveraging all hardware features, selectively enabling specific hardware acceleration like SHA acceleration, or utilizing Crypto Callbacks for mixed usage between hardware and software. For a guide on setting up the port please refer to the README.

Currently wolfSSL supports offloading the following algorithms and operations to the respective hardware:

TRNG:

  • RNG

TPU:

  • AES-CBC – 128/192/256
  • AES-GCM – 128/192/256
  • AES-ECB – 128/192/256
  • SHA-1
  • SHA-2 – 224/256/384/512

MAA (HW Accelerated Math Operations up to 2048 bits):

  • Modulate (mod)
  • Modular Addition (addmod)
  • Modular Subtraction (submod)
  • Modular Multiplication (mulmod)
  • Modular Exponentiation (expmod)
  • Modular Squaring (sqrmod)

Benchmarks:

These benchmarks were collected using a Cortex-M4 clocked at 96 Mhz included on the MAX32666 FTHR dev kit, and a bare metal implementation of our benchmark. The timer used for these benchmarks can be enabled with the addition of MAX3266X_RTC to user_settings.h for reproduction.

AES ECB/CBC/GCM:

AES-CBC and AES-ECB Hardware Acceleration provides a hefty 2x uplift in performance when compared to our Arm assembly acceleration and normal software implementations.
AES-GCM does not provide the same uplift due to the hardware not supporting GCM explicitly, but we take advantage of the ECB support of the hardware to still provide a speedup when compared to our standard software implementation.
You can enable this kind of speed up for other AES modes by adding HAVE_AES_ECB to user_settings.h.



All algorithms of SHA provide a consistent boost to performance. With our benchmark tool we see up to a 7x performance for SHA-384/512 when compared to our software implementations. As the algorithm gets simpler we see less of a performance increase, however the consistent throughput is still impressive.

Math Acceleration (RSA 2048 and ECDSA p256):

Using the Math Acceleration hardware we do see a decrease in performance for RSA 2048 and ECDSA p256 when compared to our software implementations. This is likely due to the setup and preprocessing that needs to happen before sending the operands down to the hardware.

 
 

Download:

For our official release please checkout our download page!

Questions?

For information about using MAX32666 or MAX32665 hardware acceleration in your project, or any general inquiries about supporting your project’s hardware, reach out to our support team at support@wolfSSL.com

If you have questions about any of the above, please contact us at facts@wolfSSL.com or +1 425 245 8247.

Download wolfSSL Now

X509 Attribute Certificate support

wolfSSL is adding support for X509 Attribute Certificates (ACERTs, for short), enabled with --enable-acert. This initial support includes reading, printing, and verifying. Furthermore, it uses our new ASN.1 template implementation, and supports RSA-PSS as well.

But what is an X509 Attribute Certificate, and how does it differ from the more commonly encountered X509 Public Key Certificate? Defined in RFC 5755, an Attribute Certificate is a digitally signed binding between an identity and authorization attributes. In contrast to X509 Public Key Certs, an X509 Attribute Cert does not contain a public key. However, the public key used to verify an Attribute Cert could be found in an X509 Pub Key Cert.

If you’re curious and want to learn more, check out the X509 ACERT pull request and our recently added ACERT example. The latter shows an example of using ACERT support with our openssl compatibility layer.

If you are interested in X509 Attribute Certificates support or have questions about any of the above, please contact us at facts@wolfSSL.com or +1 425 245 8247.

Download wolfSSL Now

LMS in PKCS11

Most people know that wolfSSL supports being a PKCS11 consumer. It is easy to enable this with the --enable-pkcs11 configure time flag and then trying out the examples. Now, what most people don’t realize is that we also have the ability to be a PKCS11 provider!! This is via our library called wolfPKCS11. Check out the source repo on github.

The most interesting thing about PKCS11 is that the post-quantum stateful hash-based signature scheme LMS/HSS has already been added to the PKCS11 standard. If you look at the latest specification, you can already find an example template definition for a private key:

CK_OBJECT_CLASS keyClass = CKO_PRIVATE_KEY;
CK_KEY_TYPE keyType = CKK_HSS;
CK_UTF8CHAR label[] = “An HSS private key object”;
CK_ULONG hssLevels = 123;
CK_ULONG lmsTypes[] = {123,...};
CK_ULONG lmotsTypes[] = {123,...};
CK_BYTE value[] = {...};
CK_BBOOL true = CK_TRUE;
CK_BBOOL false = CK_FALSE;
CK_ATTRIBUTE template[] = {
    {CKA_CLASS, &keyClass, sizeof(keyClass)},
    {CKA_KEY_TYPE, &keyType, sizeof(keyType)},
    {CKA_TOKEN, &true, sizeof(true)},
    {CKA_LABEL, label, sizeof(label)-1},
    {CKA_SENSITIVE, &true, sizeof(true)},
    {CKA_EXTRACTABLE, &false, sizeof(true)},
    {CKA_HSS_LEVELS, &hssLevels, sizeof(hssLevels)},
    {CKA_HSS_LMS_TYPES, lmsTypes, sizeof(lmsTypes)},
    {CKA_HSS_LMOTS_TYPES, lmotsTypes, sizeof(lmotsTypes)},
    {CKA_VALUE, value, sizeof(value)},
    {CKA_SIGN, &true, sizeof(true)}
}; 

Are you looking to use wolfSSL to consume LMS/HSS? Our wolfCrypt library already has support for LMS/HSS; want to consume it via a PKCS11 interface? Want to get ahead of the curve and start prototyping ML-KEM (FIPS 203) or ML-DSA (FIPS 204) in PKCS11? Send a message to facts@wolfSSL.com to let us know which of these you want accelerated.

If you have questions about any of the above, please contact us at facts@wolfSSL.com or +1 425 245 8247.

Download wolfSSL Now

wolfSSL 5.7.4 Release

wolfSSL release 5.7.4 is now available, with exciting optimizations for ARM devices and enhancements to post-quantum cryptography algorithms. If you’re using wolfSSL on RISC-V, we’ve also included new performance enhancements specifically for RISC-V devices. Alongside these optimizations and new features, several important fixes were made. One notable fix involves the behavior of X509_STORE_add_cert() and X509_STORE_load_locations() functions to better align with OpenSSL when the compatibility layer is enabled.

Below are some of the key changes in this release. For a more comprehensive list, refer to the ChangeLog.

New Features and Additions

  • RISC-V 64: Added new assembly optimizations for SHA-256, SHA-512, ChaCha20, Poly1305, and SHA-3 (PRs 7758, 7833, 7818, 7873, 7916).
  • DTLS 1.2 Connection ID: Implemented support for Connection ID (CID) (PR 7995).
  • DevkitPro Support: Added support for (DevkitPro)libnds (PR 7990).
  • Mosquitto: Added a port for Mosquitto OSP (Open Source Project) (PR 6460).
  • sssd: Added a port for init sssd (PR 7781).
  • eXosip2: Added support for eXosip2 (PR 7648).
  • STM32G4: Added support for STM32G4 (PR 7997).
  • MAX32665 and MAX32666: Added support for TPU hardware and ARM ASM crypto callback (PR 7777).
  • libspdm: Added support for building wolfSSL to be used in libspdm (PR 7869).
  • Nucleus Plus: Added support for use with Nucleus Plus 2.3 (PR 7732).
  • RFC5755 Attribute Certificates: Initial support for x509 attribute certificates (acerts) with --enable-acert (PR 7926).
  • PKCS#11 RSA Padding Offload: Allows tokens to perform CKM_RSA_PKCS (sign/encrypt), CKM_RSA_PKCS_PSS (sign), and CKM_RSA_PKCS_OAEP (encrypt) (PR 7750).
  • Heap/Pool Allocation: Added “new” and “delete” style functions for heap/pool allocation and freeing of low-level crypto structures (PRs 3166, 8089).

Espressif / Arduino Updates

  • Updated wolfcrypt settings.h
  • Updated Espressif SHA, utility, memory, and time helpers (PR 7955).
  • Fixed _thread_local_start and _thread_local_end for Espressif (PR 8030).
  • Enhanced benchmarking for Espressif devices (PR 8037).
  • Introduced Espressif common CONFIG_WOLFSSL_EXAMPLE_NAME in Kconfig (PR 7866).
  • Added wolfSSL esp-tls
  • Updated wolfSSL release for Arduino (PR 7775).

Post-Quantum Crypto Updates

  • Dilithium: Support for fixed-size arrays in dilithium_key (PR 7727).
  • Dilithium Precalc: Added option to use precalc with small sign (PR 7744).
  • Kyber FIPS: Allowed Kyber to be built with FIPS (PR 7788).
  • Kyber in Linux Kernel: Enabled Kyber ASM usage in Linux kernel module (PR 7872).
  • Dilithium, Kyber: Updated to final specifications (PR 7877).
  • Dilithium FIPS: Supported FIPS 204 Draft and Final Draft (PRs 7909, 8016).

ARM Assembly Optimizations

  • ARM32: Added assembly optimizations for ChaCha20 and Poly1305 (PR 8020).
  • Poly1305 Aarch64: Improved Poly1305 assembly optimizations for Aarch64 (PR 7859).
  • Poly1305 Thumb-2: Added Poly1305 optimizations for Thumb-2 (PR 7939).
  • STM32CubePack: Added ARM ASM build option to STM32CubePack (PR 7747).
  • Visual Studio: Added ARM64 support to the Visual Studio project (PR 8010).
  • Kyber ARM Optimizations: Added assembly optimizations for ARM32, Aarch64, ARMv7E-M, and ARMv7-M (PRs 8040, 7998, 7706).

If you have questions about any of the above, please contact us at facts@wolfSSL.com or +1 425 245 8247.

Download wolfSSL Now

wolfSSL wolfCrypt CSharp wrapper

wolfSSL is excited to announce additional support for wolfCrypt API’s in our CSharp (C#) wrapper. Our CSharp wrapper now includes wolfCrypt support for ECC (ECDSA/ECDHE), ECIES, RSA, ED25519/Curve25519, AES-GCM, and HASH cryptographic algorithms. The supported HASH algorithms are MD2, MD4, MD5, SHA, SHA-224, SHA-256, SHA-384, SHA-512, SHA-MD5, SHA3-224, SHA3-256, SHA3-384, SHA3-512, BLAKE2B, and BLAKE2S.

In addition to the CSharp wrapper, we supply a comprehensive test suite, `wolfCrypt-Test.cs` to test all of the supported cryptographic algorithms. The PR for these changes can be found here: PR# 3166.

To start using the wolfCrypt CSharp wrapper, please refer to the README.md, which contains useful information on how to get started. Another useful resource is the `wolfCrypt-Test.cs` suite, which shows common use cases and can help in validating your application setup.

If you have any questions about our wolfCrypt CSharp wrapper or need assistance, feel free to email us at facts@wolfssl.com or call us at +1 425 245 8247.

Download wolfSSL Now

Enhance Embedded System Security with ADI MAXQ1065 and wolfSSL

wolfSSL’s trusted partner, Analog Devices, Inc. (ADI), recently announced that integrating the MAXQ1065 with wolfSSL can significantly enhance security for IoT and embedded systems. Explore the ADI Engineer Zone blog post, Securing IoT and Embedded Systems: Integrate MAXQ1065 with wolfSSL, to discover wolfSSL’s competitive advantages and how this integration improves IoT security solutions and embedded system security applications.

If you have questions about any of the above, please contact us at facts@wolfSSL.com or +1 425 245 8247.

Download wolfSSL Now

Deprecation and Removal of TLS 1.0 / 1.1 Support from wolfSSL

As part of our quality control and review process, wolfSSL is planning removal of obsolete and deprecated TLS protocol support from our mainline TLS library. TLS 1.0 and 1.1 were introduced in 1999 and 2006 respectively, and both versions were formally deprecated by RFC 8996 in 2021. As noted in the deprecation RFC, TLS 1.0 requires support for an obsolete and insecure cipher suite based on 3DES, an algorithm that dates to 1981. Moreover, the security guarantees of both version 1.0 and version 1.1 depend on the SHA-1 algorithm introduced in 1995, already considered vulnerable in 2005, and formally retired by NIST in 2022. TLS 1.0 and 1.1 have been disabled by default in wolfSSL since release 3.13.0 (2017) and 5.6.6 (2023) respectively.

Modern TLS implementations use either TLS 1.2 or 1.3, both of which avoid dependence on obsolete and deprecated algorithms and mechanisms. Version 1.2 was introduced in 2008, is currently considered secure when configured properly, and is supported by all modern TLS implementations. Version 1.3 is the latest version, finalized in 2018, with the highest inherent security, supported by wolfSSL since release 3.11.1 (2017).

While support for obsolete and insecure protocols is useful in some specialized analytic and forensic applications, we believe that continuation of this support in our mainline products does more harm than good, due to the associated complexity, and the inherent risk of misconfiguration, with potentially critical implications for system security.

While we have not yet determined a timeline for removal of code in wolfSSL specific to TLS 1.0 and 1.1, all API support for them should be considered deprecated, consistent with RFC 8996.

If you have questions about any of the above, please contact us at facts@wolfSSL.com or +1 425 245 8247.

Download wolfSSL Now

Posts navigation

1 2 3 4 5 6