So I was just reading up on what wolfSSL has been up to lately and man they are really going hard on the embedded security stuff. It is not just one little patch either, they are hitting everything from how devices talk over a network to the scary future stuff like post-quantum cryptography and even car hardware.
Let’s talk about this wolfIP thing first because it is actually pretty interesting if you deal with bare-metal or RTOS stuff. You know how usually when you are working with networking stacks, everything is just dynamic and you hope you don’t run out of memory halfway through a session? Well, wolfIP is basically the opposite of that headache. It uses these socket tables and RX/TX packet buffers that you size during compilation. It is like, you decide the size upfront so you actually know exactly how much memory you are using before you even deploy the thing.
It makes everything way more predictable, which is a huge deal when you are working on safety-critical systems where a crash is not an option. And get this, they are saying the core is like four times smaller than lwIP. Four times! That is massive if you are fighting for every single byte of RAM. It covers the basics too, like TCP, UDP, DHCP, and DNS, and it plays nice with wolfSSL TLS 1.3.
Anyway, moving on to the heavy math side of things, which is the post-quantum stuff. This is the part that keeps security nerds up at night. They are pushing wolfCrypt even further and they actually got NIST validation through their Cryptographic Algorithm Validation Program. I saw the certificate number, A8437, if you care about that kind of stuff.
It covers ML-KEM, ML-DSA, and SLH-DSA, plus those LMS and XMSS signature verifications. They also have the usual suspects like SHA-2, SHA-3, and HMAC. It looks like they are prepping for a FIPS 140-3 v7.0.0 submission too. They want all those new algorithms inside the validated cryptographic boundary, which is a big goal.
Oh, and I almost forgot about Falcon. They added native Falcon-512 and Falcon-1024 directly into wolfCrypt. Before, you had to rely on that liboqs library, but now it is just baked in. It works on everything from tiny embedded systems to your desktop or even the Linux kernel. They even have optimized paths for x86-64 and Arm, which is great for performance. They did mention that Falcon is still experimental though, mostly because NIST is still messing around with the FN-DSA standard, so don’t go building a bank with it just yet.
Then there is FrodoKEM. They threw that into wolfCrypt too. It supports three different parameter sets and you can choose between SHAKE or AES-based matrix generation. The cool thing is you can pick and choose what you need at build time so you don’t end up with a bloated binary. It even integrates with ASN.1 and X.509, so you can actually handle those FrodoKEM keys in certificates. It is getting pretty deep.
Wait, I should probably mention the automotive side too because that is a whole different beast. wolfHSM now supports the Infineon AURIX TC4xx family. They already had support for the TC3xx, but this new one expands it. It uses this client-server setup where your app just sends crypto tasks to an isolated hardware security module core. It handles the heavy lifting for things like secure boot, OTA updates, and secure communications. If you are working with AUTOSAR, it fits right in. And they even have an ASIL-D certification package, which is basically the gold standard for safety in cars. The best part is that if you are moving from the TC3xx to the TC4xx, you don’t have to redesign your whole interface. It’s a smooth migration.
They are actually going to show all this off at embedded world North America at booth 6027. If you happen to be there, go check it out. It is a lot to take in, but it feels like they are actually building stuff that works for the real world, not just theoretical math.