Category: wolfSSL/ wolfCrypt

The wolfSSL team is announcing the deprecation of the ARC4 cipher. This decision is part of our ongoing effort to simplify the wolfSSL codebase and focus on supporting the most secure and widely-used ciphers.

The ARC4 cipher has been shown to have significant weaknesses, including:

• Key biases and correlations
• Plaintext recovery attacks
• Increased risk of data breaches

Removing ARC4 will allow us to reduce the complexity of our codebase and devote more resources to maintaining and improving our supported ciphers.

Recommendations:

• Begin transitioning away from ARC4 and towards more secure ciphers, such as AES or ChaCha20.
• Consult the wolfSSL documentation and support resources for guidance on migrating away from ARC4.

We will provide additional information on the removal timeline in the future. If you have any questions or concerns about this deprecation, please don’t hesitate to reach out to the wolfSSL support team.

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

Download wolfSSL Now

In today’s digital landscape, the need for robust authentication mechanisms has never been more crucial. Among the various methods available, SPAKE (Simple Password-Authenticated Key Exchange) stands out as an enhanced security solution for authenticating users.

SPAKE represents a significant advancement over traditional password-based authentication, which often relies on static hashes. By leveraging a shared secret key, SPAKE ensures that passwords are never directly exposed during the authentication process, thereby mitigating risks associated with compromised credential storage.

The integration of wolfSSL into the Kerberos 5 implementation further elevates security by providing FIPS 140-3 certified cryptography. This compliance ensures that cryptographic modules meet stringent security standards, crucial for organizations prioritizing data protection and regulatory adherence.

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

Download wolfSSL Now

Ladies and gentlemen, it’s story time!!

Once upon a time, there was a network administrator that only wanted to use the strongest NIST-approved ECC encryption available within the TLS 1.3 protocol. They picked ECDHE over the secp521r1 curve. When they went to code their application, they wanted the best TLS library available so they naturally picked wolfssl.

In order to let their peers know that they wanted to use ECDHE over the secp521r1 curve with TLS 1.3, they used the wolfSSL_UseKeyShare() API during the setup of the connection. With this addition they thought they were done. Like any good software developer, they then tested their application against many servers and found that it worked as expected. Happy with the results, our security conscious network administrator began using their new application.

A little while later, during a network security audit, the consultant found that the application was on some occasions using ECDHE over the secp256r1 curve!! Flabbergasted, the network administrator demanded proof and the consultant showed him the wireshark transcripts. Low and behold, the transcripts showed that the server had sent a HelloRetryRequest handshake message requesting secp256r1. This was because the SupportedGroups extension in the ClientHello had advertised support for secp256r1 and that was the only curve that this particular server supported.

In the end, the solution was simple. Our network administrator called wolfSSL_set_groups() specifying only secp521r1. The next time he connected to the offending server, it simply refused the connection. Then our administrator upgraded that server to support secp521r1. Our hero and their application and servers lived happily ever after.

– The End –

Note this parable does not constitute a bug nor vulnerability in the wolfssl library. What happened was exactly how TLS 1.3 is supposed to work. This is a case of unintended consequences due to insufficient configuration.

Another possible more bullet proof solution is to compile out support for weaker ECC curves during the configuration of the wolfssl library.

This parable is especially relevant in the era of post-quantum cryptography. If you are trying to thwart the “harvest now, decrypt later” threat model and you are willing to sacrifice some interoperability, then you do not want to advertise support for conventional algorithms.

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

Download wolfSSL Now

As part of our ongoing effort to maintain the highest level of security and performance, we are announcing the upcoming deprecation of RC2 from wolfCrypt. All of our products depend on wolfCrypt for their algorithm implementations so this could have consequences across our whole product line.

What is RC2?

RC2 is a symmetric-key block cipher that was widely used in the past for data encryption. Developed in 1987 by Ron Rivest, RC2 is now over 35 years old.

Why is RC2 being deprecated?

The main reasons for deprecating RC2 are:

• Security vulnerabilities: RC2 has been shown to be vulnerable to certain attacks, such as brute-force attacks and side-channel attacks.
• Limited key size: RC2’s key size is limited to 64 bits, which is considered too small for modern cryptographic purposes.
• Better alternatives available: TLS 1.3 forbids RC2 and now there are more secure and efficient cryptographic algorithms available, such as AES and ChaCha20.
• Regulatory requirements: The NSA has made it clear, RC2 is now obsolete. Learn more

What does this mean for our users?

We will soon be deprecating RC2 in our products and services. This means that:

• New versions of wolfCrypt: RC2 will no longer be available in future version of wolfCrypt. Are you using protocols that require RC2? Does this break compatibility with peers you communicate with? Let us know by sending a message to support@wolfssl.com
• Existing deployments: We will provide a transition period for existing deployments to migrate to a more secure algorithm.
• Support: We will no longer provide support for RC2-related issues, but we will make suggestions to help ease your transition.

What are the recommended alternatives?

We recommend using more secure and efficient cryptographic algorithms, such as:

• AES: A widely used and highly secure symmetric-key block cipher.
• ChaCha20: A fast and secure stream cipher.

We encourage our users to start planning their migration to a more secure algorithm as soon as possible.

If you have any questions or concerns, please don’t hesitate to reach out to facts@wolfSSL.com or call us at +1 425 245 8247.

Download wolfSSL Now

STMicroelectronics recently released a new range of ARM based MPUs. These are industrial grade ARM microprocessors that provide excellent performance as well as many useful features. ST have released OpenSTLinux to run on these chips, but they have also made a version of their bare-metal HAL API which works with these chips.

The wolfSSL team has recently ported wolfSSL to bare metal for the STM32MP135F in this range. This chip has a single-core 1GHz ARM Cortex-A7 which has hardware crypto acceleration features. There have been multiple parts to this work, which I will walk through in this post.

HAL porting

The previous AES, HASH and PKA HAL acceleration for STM32 MCUs has been ported to work with the STM32MP13 HAL. Every hardware acceleration feature we have previously supported for STM32 MCUs works with this MPU.

During testing, we clocked the MPU at 650MHz, which is the default high clock speed for bare-metal. At this speed we can get 12MB/sec AES-CBC, 9MB/sec AES-GCM and 90MB/sec SHA256. This is with the core clocked at only 65% of its maximum speed.

Extra hash support

We didn’t just stop there: we also added HAL acceleration for additional SHA types. With this MPU, we can now accelerate SHA-384, SHA-512 and SHA3 types. All also achieving around 85-90MB/sec. This is a 10-30x improvement over what you would typically see when running software-based algorithms for these types on the same hardware.

All the work we did to add these hash types should be easily portable to ST MCUs that support those types in the HAL. You can email us at support@wolfSSL.com if you wish for us to assist you with this porting work.

wolfSSL Example

Setting up and running the MPU in bare-metal mode can be a little bit tricky, so on top of all of this, we created a documented example so that you can create an echo client. This example is designed to be used with the STM32MP135F-DK development board. It uses FreeRTOS and LwIP, so it can be extended to do other things.

The example is available on our wolfssl-examples-stm32 GitHub repository.

There is also a README available in the main wolfSSL source tree, which can guide you through using wolfCrypt with the STM32MP135F.

What about Linux?

For those who want to use OpenSTLinux, wolfSSL “just works”. Using ST’s cross-compile toolchain, you can compile wolfSSL just like you would for any other Linux installation. On Linux, this is the wolfCrypt benchmark results:

------------------------------------------------------------------------------
 wolfSSL version 5.7.4
------------------------------------------------------------------------------
Math:   Multi-Precision: Wolf(SP) word-size=32 bits=4096 sp_int.c
        Single Precision: ecc 256 384 rsa/dh 2048 3072 4096 asm sp_cortexm.c
wolfCrypt Benchmark (block bytes 1048576, min 1.0 sec each)
RNG                         10 MiB took 1.049 seconds,    9.537 MiB/s
AES-128-CBC-enc             20 MiB took 1.003 seconds,   19.931 MiB/s
AES-128-CBC-dec             20 MiB took 1.075 seconds,   18.597 MiB/s
AES-192-CBC-enc             20 MiB took 1.198 seconds,   16.697 MiB/s
AES-192-CBC-dec             20 MiB took 1.254 seconds,   15.947 MiB/s
AES-256-CBC-enc             15 MiB took 1.063 seconds,   14.105 MiB/s
AES-256-CBC-dec             15 MiB took 1.076 seconds,   13.943 MiB/s
AES-128-GCM-enc             10 MiB took 1.044 seconds,    9.577 MiB/s
AES-128-GCM-dec             10 MiB took 1.018 seconds,    9.822 MiB/s
AES-192-GCM-enc             10 MiB took 1.130 seconds,    8.846 MiB/s
AES-192-GCM-dec             10 MiB took 1.128 seconds,    8.867 MiB/s
AES-256-GCM-enc             10 MiB took 1.191 seconds,    8.393 MiB/s
AES-256-GCM-dec             10 MiB took 1.204 seconds,    8.307 MiB/s
GMAC Table 4-bit            20 MiB took 1.014 seconds,   19.716 MiB/s
CHACHA                      35 MiB took 1.102 seconds,   31.750 MiB/s
CHA-POLY                    30 MiB took 1.173 seconds,   25.586 MiB/s
POLY1305                   120 MiB took 1.027 seconds,  116.896 MiB/s
SHA                         45 MiB took 1.029 seconds,   43.727 MiB/s
SHA-256                     25 MiB took 1.042 seconds,   23.988 MiB/s
HMAC-SHA                    45 MiB took 1.075 seconds,   41.845 MiB/s
HMAC-SHA256                 25 MiB took 1.029 seconds,   24.291 MiB/s
RSA     2048   public      1400 ops took 1.043 sec, avg 0.745 ms, 1342.619 ops/sec
RSA     2048  private       100 ops took 2.532 sec, avg 25.324 ms, 39.488 ops/sec
DH      2048  key gen        86 ops took 1.007 sec, avg 11.707 ms, 85.419 ops/sec
DH      2048    agree       100 ops took 1.194 sec, avg 11.939 ms, 83.763 ops/sec
ECC   [      SECP256R1]   256  key gen      1500 ops took 1.023 sec, avg 0.682 ms, 1466.898 ops/sec
ECDHE [      SECP256R1]   256    agree       700 ops took 1.037 sec, avg 1.482 ms, 674.714 ops/sec
ECDSA [      SECP256R1]   256     sign      1200 ops took 1.109 sec, avg 0.924 ms, 1081.961 ops/sec
ECDSA [      SECP256R1]   256   verify       700 ops took 1.146 sec, avg 1.638 ms, 610.589 ops/sec

Details on this can also be found in the wolfSSL STM32MP13 README.

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

Download wolfSSL Now

“Hey wolfSSL, care to show us Europeans some post-quantum love?”

Of course! Here at wolfSSL we were founded in the USA and most of our team is American. Naturally, we have been following NIST (National Institute of Standards and Technology) standards. That said, we love and cherish our European customers and community as well.

Cryptography and communications protocols are international in nature and interoperability requirements span across several borders and oceans. This means that we need to not only look at our own standards bodies but those of other countries as well. Examples of this include our support for the ShangMi ciphers as well as support for the Brainpool ECC (Elliptical Curve Cryptography) curves.

It has been duly noted by wolfSSL that the German BSI (Bundesamt für Sicherheit in der Informationstechnik) and other international organizations are also pushing for industry support and standardization of FrodoKEM. For our customers that are participating in German and other European markets, you can take a sigh of relief and relax. We will soon be starting work on our own implementation of FrodoKEM.

Please do reach out to us letting us know of your interest in FrodoKEM or any other new algorithms that you would like to see implemented in wolfCrypt. Your voice matters as it sets our priorities and can accelerate what we do next!

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

Download wolfSSL Now

Pretty much everyone knows what a Raspberry Pi board is, a very budget-friendly ARM board which runs Linux. What you might not know is that Raspberry Pi also created a very small, cheap, embedded ARM microcontroller range and development board as well. The board is known as the Raspberry Pi Pico and the chip is the RP2040.

The RP2040 is a $1 dual-core ARM Cortex-M0+ microcontroller with lots of features and a very well documented SDK. It was followed-up recently with the RP2350, which, for a similar price, gets you a dual-core ARM Cortex-M33 / RISC-V microcontroller. The RP2350 can be found on the Pi Pico 2 boards.

wolfSSL support

wolfSSL has had basic support for RP2040 for a little while, but with wolfSSL 5.7.6, we have provided improvements to the support. In addition, we have added support for the RP2350.

For both microcontrollers, we have enhanced the performance for RNG. We have integrated support for the PRNG in the Pico SDK for the RP2040 and the TRNG in the RP2350. Both provide performance improvements.

With the RP2350, we have also added support for the RISC-V mode for the cores.

Benchmark

What about the numbers? Well, with a RP2350 in ARM mode, clocked at the default 150MHz, these are the numbers you can expect to see from the wolfCrypt Benchmark:

wolfCrypt Benchmark (block bytes 1024, min 1.0 sec each)
RNG                          3 MiB took 1.001 seconds,    2.855 MiB/s
AES-128-CBC-enc              3 MiB took 1.004 seconds,    2.529 MiB/s
AES-128-CBC-dec              3 MiB took 1.000 seconds,    2.588 MiB/s
AES-192-CBC-enc              2 MiB took 1.007 seconds,    2.157 MiB/s
AES-192-CBC-dec              2 MiB took 1.005 seconds,    2.234 MiB/s
AES-256-CBC-enc              2 MiB took 1.009 seconds,    1.888 MiB/s
AES-256-CBC-dec              2 MiB took 1.003 seconds,    1.898 MiB/s
AES-128-GCM-enc            900 KiB took 1.003 seconds,  897.418 KiB/s
AES-128-GCM-dec            925 KiB took 1.015 seconds,  911.157 KiB/s
AES-192-GCM-enc            850 KiB took 1.006 seconds,  844.758 KiB/s
AES-192-GCM-dec            875 KiB took 1.021 seconds,  856.974 KiB/s
AES-256-GCM-enc            825 KiB took 1.029 seconds,  802.085 KiB/s
AES-256-GCM-dec            825 KiB took 1.015 seconds,  812.705 KiB/s
AES-128-GCM-enc-no_AAD    1000 KiB took 1.017 seconds,  983.142 KiB/s
AES-128-GCM-dec-no_AAD    1000 KiB took 1.004 seconds,  995.881 KiB/s
AES-192-GCM-enc-no_AAD     925 KiB took 1.004 seconds,  921.384 KiB/s
AES-192-GCM-dec-no_AAD     950 KiB took 1.018 seconds,  933.496 KiB/s
AES-256-GCM-enc-no_AAD     875 KiB took 1.007 seconds,  868.579 KiB/s
AES-256-GCM-dec-no_AAD     900 KiB took 1.024 seconds,  879.291 KiB/s
GMAC Table 4-bit             2 MiB took 1.000 seconds,    2.488 MiB/s
CHACHA                       6 MiB took 1.004 seconds,    6.397 MiB/s
CHA-POLY                     4 MiB took 1.001 seconds,    4.024 MiB/s
POLY1305                    21 MiB took 1.000 seconds,   20.868 MiB/s
SHA                          6 MiB took 1.000 seconds,    6.493 MiB/s
SHA-256                      2 MiB took 1.010 seconds,    2.224 MiB/s
SHA-384                      1 MiB took 1.013 seconds,    0.988 MiB/s
SHA-512                    975 KiB took 1.019 seconds,  956.876 KiB/s
SHA-512/224                775 KiB took 1.000 seconds,  774.960 KiB/s
SHA-512/256                  1 MiB took 1.024 seconds,    0.978 MiB/s
SHA3-224                     1 MiB took 1.001 seconds,    1.171 MiB/s
SHA3-256                     1 MiB took 1.013 seconds,    1.109 MiB/s
SHA3-384                   875 KiB took 1.017 seconds,  860.133 KiB/s
SHA3-512                   625 KiB took 1.032 seconds,  605.855 KiB/s
SHAKE256                     1 MiB took 1.013 seconds,    1.109 MiB/s
HMAC-SHA                     6 MiB took 1.001 seconds,    6.463 MiB/s
HMAC-SHA256                  2 MiB took 1.007 seconds,    2.206 MiB/s
HMAC-SHA384               1000 KiB took 1.012 seconds,  987.685 KiB/s
HMAC-SHA512                950 KiB took 1.010 seconds,  940.914 KiB/s
RSA     2048   public       226 ops took 1.004 sec, avg 4.442 ms, 225.121 ops/sec
RSA     2048  private         8 ops took 1.093 sec, avg 136.666 ms, 7.317 ops/sec
DH      2048  key gen        16 ops took 1.015 sec, avg 63.442 ms, 15.762 ops/sec
DH      2048    agree        16 ops took 1.009 sec, avg 63.034 ms, 15.864 ops/sec
ECC   [      SECP256R1]   256  key gen        46 ops took 1.034 sec, avg 22.489 ms, 44.466 ops/sec
ECDHE [      SECP256R1]   256    agree       108 ops took 1.004 sec, avg 9.292 ms, 107.615 ops/sec
ECDSA [      SECP256R1]   256     sign        42 ops took 1.017 sec, avg 24.226 ms, 41.278 ops/sec
ECDSA [      SECP256R1]   256   verify        96 ops took 1.015 sec, avg 10.569 ms, 94.614 ops/sec
CURVE  25519  key gen       103 ops took 1.006 sec, avg 9.762 ms, 102.433 ops/sec
CURVE  25519    agree       106 ops took 1.015 sec, avg 9.575 ms, 104.437 ops/sec
ED     25519  key gen       101 ops took 1.005 sec, avg 9.952 ms, 100.479 ops/sec
ED     25519     sign        80 ops took 1.019 sec, avg 12.741 ms, 78.484 ops/sec
ED     25519   verify        76 ops took 1.020 sec, avg 13.427 ms, 74.477 ops/sec
CURVE    448  key gen        25 ops took 1.014 sec, avg 40.580 ms, 24.643 ops/sec
CURVE    448    agree        26 ops took 1.034 sec, avg 39.770 ms, 25.144 ops/sec
ED       448  key gen        34 ops took 1.027 sec, avg 30.219 ms, 33.092 ops/sec
ED       448     sign        32 ops took 1.030 sec, avg 32.187 ms, 31.069 ops/sec
ED       448   verify        22 ops took 1.098 sec, avg 49.900 ms, 20.040 ops/sec
Benchmark complete

For the RP2040, you can expect around 33-50% of this performance at the default 125MHz.

wolfBoot support

We are not stopping at just plain wolfSSL, we have a port of wolfBoot in-development to allow for secure bootloading of the RP2350 microcontroller. We will announce more details about this soon.

How do I try this?

We have a wolfSSL example available in our wolfSSL Examples repository. For more information, you can reach out to us for help at facts@wolfSSL.com or +1 425 245 8247.

Download wolfSSL Now

wolfSSL FIDO Compliance

As organizations move away from traditional password-based authentication, FIDO (Fast Identity Online) has emerged as one of the leading standards for strong authentication. wolfSSL is positioned to support this transition with our robust cryptography library, wolfCrypt, which implements many of the core algorithms required for FIDO compliance. This blog outlines how wolfSSL can serve as a foundation for FIDO-compliant authentication solutions.

FIDO and Why It Matters

FIDO (Fast Identity Online) Alliance maintains strict standards for cryptographic implementations in authentication systems with a mission to reduce the reliance of passwords. With wolfCrypt implementing most of the FIDO-approved algorithms, this means wolfSSL can provide developers with a compliant cryptographic foundation for their FIDO authentication solutions for both large, web-connected systems as well as embedded microcontrollers.

Existing FIDO-Approved Algorithms

wolfSSL already implements many of the cryptographic algorithms from FIDO’s allowed cryptography list^[1], including:

• SHA-256, SHA-384, SHA-512, SHA3-256, SHA3-384 and SHA3-512
• HMAC capabilities with the allowed hash functions
• HMAC implementation for secure message authentication
• AES-CMAC support for lightweight authentication
• AES-GCM for authenticated encryption
• RSA PSS and PKCS#1 v1.5 signature support
• Ed25519 signatures

The only missing algorithms in wolfSSL are the implementation of ED256, ED256-2, ED512 and ED638.

wolfSSL also meets FIDO’s deterministic random number/bit generator requirements as wolfCrypt is NIST FIPS 140-2/3 compliant which uses NIST SP800-90A HASH_DRBG as well as NIST SP800-90B compliant entropy generation.

Potential Integration with FIDO2 Applications and Libraries

FIDO2 is the latest authentication standard that enables passwordless and strong two-factor authentication through the Web Authentication (WebAuthn) API and Client-to-Authenticator Protocol (CTAP). With there already being FIDO2 applications on the market wolfSSL can easily be implemented directly or automatically with the compatibility layer or engine/provider OpenSSL replacement. For instance Yubico’s libfido2 library which uses OpenSSL could be ported to use wolfCrypt instead.

A wolfSSL employee has also been working on a project that uses 2FA with wolfCrypt on a Raspberry Pi Pico called Fidelio.

FIPS 140-3 and FIDO2

Organizations requiring both FIDO2 and FIPS 140-3 compliance can leverage wolfCrypt’s FIPS 140-3 validated module, which provides CAVP and FIPS validated implementations of essential FIDO algorithms. This dual compliance ensures solutions meet both authentication standards and regulatory requirements.

Looking Forward

Contact us at facts@wolfSSL.com or +1 425 245 8247 for question about comprehensive support for integrating wolfCrypt into your FIDO2 applications, including:

• Technical consultation for implementation
• Documentation and example code
• Integration with hardware security modules
• Optimization for embedded systems
• Custom builds for specific platforms

Resources

^[1] “FIDO Authenticator Allowed Cryptography List,” FIDO Alliance, 2023.

Download wolfSSL Now

wolfSSL now has support for Renesas RX TSIP with ECDSA and crypto callbacks. This update provides broader flexibility and security for embedded systems with Renesas RX TSIP. Below is a summary of the key changes and updates that were added in PR# 7685:

Key Changes and Features

1. Renesas RX TSIP with ECDSA Support
   WolfSSL now fully supports ECDSA on Renesas RX TSIP, which adds greater functionality when generating signatures. The update also adds support for raw R+S signatures.
2. ECC with NO_ASN
   You can now use ECC support without ASN.1 encoding by using the configuration:
   ‘./configure –enable-cryptonly –disable-rsa –disable-asn –disable-examples’
   This can decrease the overhead in environments where you don’t need ASN.1 support.
3. RX TSIP Crypt Configuration Fixes
   These changes also fixes issues with WOLFSSL_RENESAS_TSIP_CRYPTONLY and NO_WOLFSSL_RENESAS_TSIP_CRYPT_HASH macros, allowing for builds to complete smoothly when there is only a requirement for cryptography operations.
4. Reverted wc_GenerateSeed Support
   wc_GenerateSeed on the RX TSIP was reverted. This ensures compatibility with the updated RNG on RX TSIP.
5. Updated Client Authentication Key Data
   Example key data with private key for client authentication has been updated.

Testing

These changes were tested using the e2Studio IDE, and tests were verified including client and server examples.

Conclusion

These updates extend wolfSSL’s support of the Renesas RX TSIP to include ECDSA and Raw R+S signature support, greatly improving flexibility and optimizing the build for embedded systems. If you have questions about any of the above, please contact us at facts@wolfSSL.com or +1 425 245 8247.

Download wolfSSL Now