wolfCLU v0.1.4
wolfCLU version 0.1.4 is now available! In this release of the wolfSSL command line utility (CLU) there were additions to the x509 command, more subject alternative name attributes supported, and a couple of minor fixes / maintenance items. The command line utility is a great time saver for quickly creating keys, certificates, signatures, and hashes with wolfSSL.
For questions about wolfCLU and its use or if you have questions about any of the above, please contact us at facts@wolfSSL.com or call us at +1 425 245 8247.
Download wolfSSL Now
wolfSSL is extending wc_PKCS7_VerifySignedData streaming
wolfSSL, a TLS library for embedded devices, not only handles the TLS protocol, but also supports bundle file handling functions specified by PKCS#7 (bundle file encoding, decoding, content extraction, signature verification). wolfSSL continues to extend this PKCS#7 handling functionality.
wolfSSL is currently extending our wc_PKCS7_VerifySignedData() API to handle PKCS#7 bundle data with multipart and indefinite length content in a streaming manner. This enhancement allows bundle data with relatively large content to be served sequentially by streaming, rather than buffering it all and then processing it.
If you have questions about any of the above, please contact us at facts@wolfSSL.com or call us at +1 425 245 8247.
Download wolfSSL Now
wolfSSL Updated Support for Kerberos 5 1.21.1
wolfSSL release 5.6.4 includes support for Kerberos 5 1.21.1. Kerberos is a network authentication protocol using modern cryptography to secure communications. The cryptography in the protocol is strong enough so that a client can prove its identity to a server (and vice versa) across an insecure network connection. You can improve the security of Kerberos to a FIPS 140-2 (and 140-3 coming soon!) level by using wolfSSL as the cryptographic and TLS backend.
wolfSSL and wolfCrypt are Federal Information Processing Standards (FIPS) 140-2 certified. This is a mandatory standard for the protection of sensitive or valuable data within Federal systems. We are working very hard on certifying our products to FIPS 140-3. wolfSSL and wolfCrypt will be FIPS 140-3 certified very soon. By using wolfSSL, you can achieve a full (D)TLS 1.3 connection that is fully FIPS compliant.
For more information about using Kerberos with wolfSSL or FIPS certification, please contact us at facts@wolfSSL.com or call us at +1 425 245 8247.
Download wolfSSL Now
Live Webinar: FIPS 140-3 OE additions and planning for 2024 and beyond
Join us for the highly anticipated FIPS 140-3 webinar! Save the date for our insightful session, ‘FIPS 140-3 OE Additions and Planning for 2024 and Beyond,’ led by wolfSSL’s Senior Software Engineer, Kaleb, scheduled for December 7th at 10 am PT. wolfSSL, a leader in embedded FIPS certificates, is on the verge of certifying wolfCrypt for FIPS 140-3.
Watch the webinar here: FIPS 140-3 OE Additions and Planning for 2024 and Beyond
Discover the latest updates and exciting news during this webinar, including:
- Progress updates and status of our FIPS 140-3 pursuit
- Notable differences between 140-2 and 140-3 standards
- Insights on Post-Quantum and NSA 2.0 Suite
- Engage with us during Q&A, offering input for our next submission
In this session, Kaleb will share exclusive insights into FIPS 140-3, providing valuable information to align your projects with FIPS requirements. Watch it now!
As always, our webinars will include Q&A sessions throughout. If you have questions on any of the above, please contact us at facts@wolfSSL.com or call us at +1 425 245 8247.
Download wolfSSL Now
wolfSSL Support for Nginx 1.25.0 and 1.24.0
In wolfSSL release 5.6.4, we have updated support for Nginx versions 1.24.0 and 1.25.0. Nginx is a high-performance, high-concurrency web server which is compact, fast, and highly scalable. This makes wolfSSL a good choice for the TLS backend. wolfSSL is an embedded SSL/TLS library which supports a wide range of architectures and operating systems.
The instructions to build Nginx with wolfSSL can be found at https://github.com/wolfSSL/wolfssl-nginx
If you have any questions about using Nginx with wolfSSL, please contact us at facts@wolfSSL.com or call us at +1 425 245 8247.
Download wolfSSL Now
Support for DTLS 1.3 early data
The wolfSSL implementation of DTLS 1.3 supports Early Data or 0-RTT Data. Early Data is application data that can be sent by the client with the very first ClientHello message. It is also called 0-RTT Data because it requires 0 Round Trip Time before application data can be sent. To utilize Early Data in DTLS 1.3, the server needs to omit the cookie exchange when using a PSK connection. The handshake using Early Data is presented in the following figure.
Client Server
ClientHello
+ early_data
+ key_share
+ psk_key_exchange_modes
+ pre_shared_key
Early Data -------->
ServerHello
+ pre_shared_key
+ key_share
EncryptedExtensions
+ early_data
Finished
<-------- Application Data
EndOfEarlyData
Finished -------->
Application Data <-------> Application Data
To use DTLS 1.3 Early Data in wolfSSL without the cookie exchange, the server needs to be modified:
- Compile wolfSSL with WOLFSSL_DTLS13_NO_HRR_ON_RESUME defined
- When compiling with configure add CPPFLAGS=-DWOLFSSL_DTLS13_NO_HRR_ON_RESUME
- When compiling with user settings add #define WOLFSSL_DTLS13_NO_HRR_ON_RESUME
- Call wolfSSL_dtls13_no_hrr_on_resume(ssl, 1) on the WOLFSSL object to disable the cookie exchange on resumption
- Continue like with a normal connection
Early Data is protected by using the cipher material associated with the PSK (pre-shared key). This can either be the cipher material of the previous connection when using a ticket or out-of-band cipher material when using a real PSK. As a result of using previous cipher material, Early Data can compromise PFS (Perfect Forward Secrecy).
For any questions about DTLS 1.3 and Early Data in wolfSSL, please contact us at facts@wolfssl.com or call us at +1 425 245 8247.
Download wolfSSL Now
Aarch64 Gets a Performance Boost in wolfCrypt
We at wolfSSL are continuously improving performance of the wolfCrypt code. Recently we took a look at our AES-GCM on Aarch64 and thought: we can do better.
By using the cryptographic instructions built into Aarch64 chips we had already gotten a significant boost over straight C but we saw that we could do more. By unrolling loops, interleaving the GCM calculation with AES encryption and using NEON as well as the base instructions at the same time, we were able to see a significant improvement!
How significant? Up to 9.5 times faster! The wolfSSL 5.6.4 numbers on an Apple M1 were:
------------------------------------------------------------------------------ wolfSSL version 5.6.4 ------------------------------------------------------------------------------ wolfCrypt Benchmark (block bytes 1048576, min 1.0 sec each) AES-128-GCM-enc 1845 MB took 1.000 seconds, 1845.382 MB/s AES-128-GCM-dec 907 MB took 1.005 seconds, 902.210 MB/s AES-192-GCM-enc 1845 MB took 1.002 seconds, 1842.527 MB/s AES-192-GCM-dec 902 MB took 1.002 seconds, 900.038 MB/s AES-256-GCM-enc 1845 MB took 1.000 seconds, 1844.793 MB/s AES-256-GCM-dec 897 MB took 1.001 seconds, 895.873 MB/s Benchmark complete
And now with the new assembly code:
------------------------------------------------------------------------------ wolfSSL version master ------------------------------------------------------------------------------ wolfCrypt Benchmark (block bytes 1048576, min 1.0 sec each) AES-128-GCM-enc 8583 MB took 1.000 seconds, 8580.862 MB/s AES-128-GCM-dec 8583 MB took 1.000 seconds, 8580.389 MB/s AES-192-GCM-enc 7875 MB took 1.001 seconds, 7870.179 MB/s AES-192-GCM-dec 7922 MB took 1.000 seconds, 7921.097 MB/s AES-256-GCM-enc 7067 MB took 1.000 seconds, 7064.394 MB/s AES-256-GCM-dec 7230 MB took 1.001 seconds, 7225.034 MB/s Benchmark complete
Try it out and you will see that the encryption and decryption of TLS packets will appear insignificant.
Are there other algorithms on Aarch64 whose performance you would like to see us improve? Let us know!
If you have questions about any of the above, please contact us at facts@wolfSSL.com or call us at +1 425 245 8247
Download wolfSSL Now
Windows support added for our software-based source of entropy (wolfEntropy)
wolfEntropy, a software-based entropy source developed by the wolfSSL team, leverages timing jitter variations in memory accesses across various cache levels to generate entropy. It has been available since wolfSSL v5.5.4, and support for Windows has been introduced. This eliminates the need for hardware redesign to incorporate a hardware-based entropy source.
The first general purpose high performance software entropy source is available now!
It is designed to fully conform with SP800-90B. The SP800-90B is a publication by the National Institute of Standards and Technology (NIST) that specifies the requirements for entropy sources used in cryptographic applications.
The wolfEntropy library source is undergoing testing to meet the criteria of a certified entropy source as outlined in the publication. It will soon proceed through the FIPS Entropy Source Validation (ESV) process.
The design of wolfEntropy is depicted in this figure:
When dealing with Unix-style systems that employ autoconf/autotools for configuring the wolfCrypt cryptographic module and integrating wolfEntropy as a component, you need to adhere to these basic configuration prerequisites:
Using Auto-tools:
./configure –enable-entropy-memuse=nofallback
Enabling the nofallback feature is crucial in this context. It restricts the system from using any other entropy source apart from wolfEntropy, even if wolfEntropy experiences a failure in any of its health tests. This strict condition ensures SP800-90B compliance.
For Windows and systems using user_settings.h to fine-tune the wolfCrypt cryptographic module along with wolfEntropy as a component, you can configure your CFLAGS with the following options:
CFLAGS=”-DHAVE_ENTROPY_MEMUSE -DWOLFSSL_SHA3 -DENTROPY_MEMUSE_FORCE_FAILURE”
Much like the Unix-style systems, the ENTROPY_MEMUSE_FORCE_FAILURE option is pivotal. It disables the use of any other entropy source, allowing only wolfEntropy to be utilized. This adherence to ENTROPY_MEMUSE_FORCE_FAILURE ensures SP800-90B compliance.
If you have questions about any of the above, please contact us at facts@wolfSSL.com or call us at +1 425 245 8247.
Download wolfSSL Now
Live Webinar: wolfSSL and Automotive Hardware Security Modules (HSMs)
Join us on an informative webinar about wolfSSL and Automotive Hardware Security Modules (HSMs) presented by wolfSSL Software Engineer, Bill, on November 30th at 10 am PT. In today’s automotive landscape, vehicles have transformed into sophisticated digital systems, making automotive cybersecurity a paramount concern.
During this webinar, Bill will delve into the world of HSMs and explore how wolfSSL is dedicated to safeguarding data in connected vehicles.
Watch the webinar here: wolfSSL and Automotive Hardware Security Modules (HSMs)
Sneak peek of the webinar
- Automotive HSM Features and benefits
- Exploring wolfHSM Functional Design
- wolfHSM Applicability to Standards
- wolfHSM Hardware Ports and Plans
- wolfHSM Demo on Infineon Aurix Tricore TC3xx
- Future Targets of wolfHSM technology
- And much more
Don’t miss this opportunity to expand your knowledge and technical skills in Automotive HSMs. Discover the full potential that wolfSSL products can offer and how wolfSSL products enhance automotive security. Bring all your questions related to Automotive HSMs and get ready to learn insights on automotive HSMS from Bill.
If you have questions about any of the above, please contact us at facts@wolfSSL.com or call us at +1 425 245 8247.
Download wolfSSL Now
wolfSSL adds ShangMi ciphers and algorithms SM2, SM3, and SM4 to wolfCrypt
As many people know, Chinese government regulators are now mandating use of SM2, SM3 and SM4 in critical systems, including automobiles, avionics, power systems, and communication systems. Since many of our customers are multi-nationals that do business in China, they have been requesting the addition of these algorithms in wolfSSL products.
Today we are about to release our supported versions of SM2, SM3, and SM4, with the intention to release the ZUC stream cipher at some point this year to completely satisfy SM9. We are also in contact with labs regarding support of OSCCA certification at some point in the future.
This is really great news for our customers selling into Chinese markets!
For those readers considering using wolfSSL products, here’s some additional notes:
- The SM Ciphers will be fully supported in wolfSSL’s TLS 1.3 implementation.
- wolfSSH, wolfBoot and our other products will support ShangMi ciphers.
- ARM, Intel, and RiscV assembly is in the works for our SM implementations for maximum performance.
- We will continue to support bare metal for ZUC, SM2, SM3, and SM4.
- True to form, we have maximized performance and minimized size, so the ShangMi algorithms will work well for embedded systems use cases on a wide variety of microcontrollers (MCU’s). They will be available for all of the MCU silicon that we currently support, including STM32, NXP i.MX, RISC-V, Renesas RA, RX, and Synergy, Nordic NRF32, Microchip PIC32, Infineon Aurix, TI MSP, and many others.
- Our GPLv2 licensed versions of the SM ciphers will be made available on GitHub and for download.
Commercially licensed versions are available.
If you have questions about our support for the ShangMi ciphers and algorithms, please contact us at facts@wolfSSL.com, or call us at +1 425 245 8247.
Download wolfSSL Now