Jan 18, 2026

The above is the set of tests against primitive algorithms in wolfssl. For the past couple of days I've been working on the suite of wolfssl unit tests that set up client-server socket communication and perform TLS communication using various protocol variations. There's about 300 of them in the suite of protocols I've set up. Most of this was just getting configuration right, along with a little bit of de-linting. The verbose output is crazy detailed and really shows how complex tls is in all of its variations. So both of these test suites are now integrated into network test. This include their certificates and test driver text files. boost::asio::ssl::socket compiles cleanly against it, and boost invokes wolfssl context startup and shutdown, using its openssl compat interface, just as a consequence of including <boost/asio/ssl.hpp>. I've also set up a define that can be used to exclude the internal implementation, which would allow the library to be linked against and headers included against openssl, an external wolfssl, or any other compatible library. The internal sources are mostly in their original file layout, and I haven't yet stripped out any unused source files. So the whole library is present, apart from test data and certs that don't get used (old protocols we don't compile). The compile of wolf is entirely isolated from our sources and only takes a few seconds. I will eventually use the already enabled callbacks to invoke our own hardware optimized sha256, hmac and hkdf, which gives us less code (no redundancy) without the ugly compiler config and raw assembly (which also doesn't work in vc++). The library and its integration with boost give us file system based certificate management.