wolfSSL 5.5.1 is released! wolfSSL 5.5.1 contains some fixes, feature additions, and one vulnerability fix.
The vulnerability fix in this minor release was thanks to a report from Max at the trail of bits, and the team working on tlspuffin. It involved TLS 1.3 on the server side with –enable-session-tickets turned on. Our recommendation is that users always try to stay up to date with the latest releases, if using TLS 1.3 on the server side and having –enable-session-tickets enabled when building wolfSSL, users should update the version of wolfSSL.
This minor release also saw the addition of sphincs and kyber, two post quantum algorithms. Non blocking ECC in the TLS layer support was added, performance optimizations for use on ARMv7 among other architectures, along with porting work for use with the NXP RT685 board.
As TrueNuff.tv demonstrated in their “Does it blend?” series, by using a blender you will find out what things are really made of. Inspired by this, wolfSSL sponsored a new QUIC related test suite for the ngtcp2 project. What does it do and how does it help you in using wolfSSL?
Ngtcp2 is the leading open source QUIC implementation. We added wolfSSL support to it, as covered in our blog. Next to wolfSSL, most other TLS/SSL libraries are also supported: the quictls fork of OpenSSL, BoringSSL, GnuTLS, picotls. Libressl is expected to join soon. (OpenSSL itself is missing and is not expected to play a role in QUIC for the foreseeable future. We covered that in the mentioned blog post.)
What you as a user of wolfSSL are most interested in is not only that you get state-of-the-art TLS, but that it communicates correctly and efficiently with all the other TLS libraries out there. Now and for all future releases coming.
QUIC’s use of TLS is very similar to TCP, but there are some differences. By testing TLS libraries against each other in the context of QUIC, we can verify not only interop for QUIC itself, but stress combinations of features and configurations that are used in “normal” TLS connections as well.
The Blender
The ngtcp2 test suite has become part of ngtcp2 itself. It is added to its CI on github, so all future development and new releases – of wolfSSL and all other TLS implementations – are always verified.
You can run this yourself. On ngtcp2’s github are the instructions to checkout and build it yourself. The new test suite has its own README, explaining how to use it. The test suite is based on Python’s pytest and should run on all platforms that support it.
There are “examples” server and client executables in ngtcp2, one for each TLS library that you configured. Should you only configure `–with-wolfssl`, only the wolfSSL server and client are built. The test suite then verifies in various scenarios that they interoperate.
If you configure more TLS libraries in ngtcp2, say `–with-wolfssl –with-openssl`, then you get two servers and two clients. The tests then try all possible combinations: wolfssl-wolfssl, openssl-openssl, openssl-wolfssl and wolfssl-openssl. Meaning, you do not need all the TLS libraries to run the blender on your machine.
Should you develop your own QUIC application, the test suite is an excellent place to verify it. It runs executables against each other. It is fairly straightforward to modify it for your own purposes.
We are, for example, currently considering how to use it for testing curl, the swiss army knife for internet transfers, sponsored by wolfSSL. We added wolfSSL QUIC support in curl, using ngtcp2, and the test coverage there needs to be extended as well.
For All
We think by donating this test suite to the ngtcp2 project, it’ll serve everyone best. We could have made it part of wolfSSL’s CI suites, but that would be a barrier for other TLS projects to pick it up. Also, should interop problems arise, let’s say between GnuTLS and BoringSSL, we do not really want to be involved in resolving it.
This aspect of OSS where things can be added and stay accessible where they make most sense is a real strength. We are happy to contribute.
wolfCLU 0.1.0 is available! wolfCLU is the wolfSSL’s Command Line Utility and is meant to be used for simple key generation, certificate operations, encryption, and more. It is also being developed to be an alternative for the commonly used OpenSSL command line utility. In addition to supporting platforms like Windows and FreeRTOS, there were vast feature enhancements over the last release. Support for several new flags were added in.
The cURL Project and wolfSSL is happy to announce the annual cURL Developers Conference, cURL Up has been rescheduled for Thursday September 15, 2022! cURL Up will be held virtually this September giving allowing the world – wide cURL community to join.
cURL Up is the annual curl developers conference where we gather and talk Internet protocols, curl’s past, current situation and how to design its future.
This is an intimate and very friendly meetup where you will have the opportunity to talk to Daniel Stenberg, founder and maintainer of cURL, as well as other speakers and sponsors about cURL and related technologies.
The first 50 registrants get some awesome swag!
When: Sep 15, 2022 06:00 AM Pacific Time (US and Canada)
wolfSSL’s controlled and maintained Application Binary Interface (ABI) coverage has been extended by 50 APIs to now have a total of 113. This includes parts of wolfCrypt including the Certificate APIs. This ensures that these APIs do not change over time so that any application using them will not be negatively impacted by upgrading to future releases of wolfSSL.
One of our goals at wolfSSL is to make sure that adopting our leading edge security solutions is as easy as possible. This includes helping our customers transition from an older version of wolfSSL to the latest version, with enhanced security, as easy as possible. The ABI coverage is one part in helping our customers with a smooth and easy transition.
Do you have questions about our ABI coverage?
Would you like to request enhancements or additional coverage?
Here at wolfSSL, we think it is fair to say that we’ve been as busy as beavers with our post-quantum efforts! Here is a round up of updates on our post-quantum efforts over the last few weeks of summer.
Webinar with Guest Speaker Professor Douglas Stebila
Want to get a better understanding of what is going on when you do a post-quantum key exchange using Kyber KEM and hear some of the latest news on post-quantum cryptography? Tune in to our recent webinar with professor Douglas Stebila where he eases in on the inner workings of the Kyber KEM algorithm and how it works. You can find the video here: https://youtu.be/nOcRk5jVGYU .
Dilithium in wolfSSL
We have added support for all parameter sets of Dilithium in the NIST Round 3 submission. This includes levels 1, 3 and 5 of the SHAKE and AES variants. Of course we have full interoperability with the OQS’s OpenSSL fork for X.509 certificates and TLS 1.3.
SPHINCS+ in wolfCrypt
We have added support for a limited number of parameter sets of the NIST Round 3 submission of SPHINCS+. This includes levels 1, 3 and 5 of fast and small optimizations of the SHAKE simple variant . Notably we did not include the robust variant. We also did not include the SHA256 variant nor the Haraka variant. Since signatures are fairly large, we did not integrate SPHINCS+ into our TLS 1.3 implementation. SPHINCS+ is more appropriate for other protocols. For example, code signing. Of course we have full interoperability with the OQS’s OpenSSL fork for X.509 certificates if you enable the variants we support in OQS’s OpenSSL fork. We have instructions for that here: https://github.com/wolfSSL/osp/blob/master/oqs/README.md
With the new integrations of Dilithium and SPHINCS+ along with our previous integrations of Kyber and Falcon, we now have coverage of all the algorithms that are moving on from NIST’s PQC Competition to standardization!
P256-kyber hybrid in wolfSSH
Originally we had integrated Saber KEM into wolfSSH, but it had been announced that it will no longer be considered for standardization. As such, instead of removing it from wolfSSH, we decided to replace it with ECDHE over the P-256 curve hybridized with Kyber Level1. Of course this has full interoperability with OQS’s fork of OpenSSH. Please give it a try by fetching from our wolfSSH github repo!
Blog PQ and DTLS 1.3
Credit goes to Callum McLoughlin of the University of Cantebury, one of our newest contributor to wolfSSL, for enabling post-quantum key exchange KEMs in DTLS 1.3. He’s done an excellent job making changes and testing them out all while keeping the wolfSSL team informed of his progress. Thanks so much Callum!
If all of this still isn’t enough for you, then show up at our booth at ICMC 2022. Our engineers and business staff would love to talk about post-quantum cryptography with you!
