RECENT BLOG NEWS

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

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

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

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