Category: Uncategorized

We are excited to announce that wolfCrypt now supports the EAX mode of operation for AES!

AES EAX is a two-pass authenticated encryption scheme that is optimized for simplicity and efficiency. More details about the algorithm can be found in EAX: A Conventional Authenticated-Encryption Mode, by M. Bellare, P. Rogaway, and D. Wagner.

To enable AES EAX in your wolfSSL build, simply pass the –enable-aeseax flag to configure. If you are building without autotools, you must define the WOLFSSL_AES_EAX preprocessor macro, as well as enable support for the AES CTR and CMAC algorithms by defining WOLFSSL_AES_COUNTER, WOLFSSL_AES_DIRECT, and WOLFSSL_CMAC.

The AES EAX API and a brief usage example can be found in the wolfCrypt AES API documentation. For a complete example, please refer to the aes_eax_test() function in wolfcrypt/test/test.c.

Please contact us at facts@wolfSSL.com or call us at +1 425 245 8247 with any questions, comments, or suggestions.

Download wolfSSL Now

Are you interested in integrating wolfSSL into OpenSC for smart card support?

We’ve been pondering this idea as well, especially after hearing from a few customers. But, we’re eager to know if there’s a broader interest out there and would greatly appreciate your feedback.

If the prospect of using wolfSSL within OpenSC intrigues you, we’d love to hear from you! Please don’t hesitate to reach out to us at facts@wolfssl.com. Your insights and input can play a crucial role in making this integration a reality. Let’s explore the potential together!

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

The FIPS Training Webinar returns on October 12th at 10 AM PT, presented by wolfSSL Senior Software Engineer Kaleb. Join us for an exciting opportunity to enhance your understanding of FIPS and gain valuable insights into its implementation from wolfSSL as the current leader in embedded FIPS certificates.

Watch the webinar here: FIPS Training Webinar

Sneak peek of the webinar:

• Public resources for the FIPS module
• The Security Policy
• Locating and using the User Guide or Cryptographic Officer Manual
• Quick recap of the material
• Best Security Practices at the application level

Kaleb will provide in-depth insights of FIPS. This is your exclusive opportunity to expand your knowledge and familiarity with FIPS. Bring all your FIPS-related questions; Kaleb is ready to answer them all.

Watch it now!

As always, our webinars will include Q&A sessions throughout. 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

TLS provides end-to-end encryption on one connection. You are routing data in and out from one application. (Note, this application can be a tunneling utility, see Stunnel.) It authenticates the server with a certificate chain of trust going back to a root CA that you implicitly trust to sign identities. It can authenticate the client to the server the same way, or can keep the client anonymous. Many protocols used over TLS provide authentication, like putting up a webpage to sign in on for your bank.

SSH provides an end-to-end encryption for a collection of data channels on one connection. Each channel can be a shell, a pseudo-terminal, an application, port forwarding, etc. It is routing STDIN and STDOUT (and STDERR) over the channel for a command. (SFTP is just a command run in a channel over the connection. SCP is as well, but these days SCP is implemented in SFTP commands.) You may be connected to a shell and not realize you are running multiple channels over your connection. (You might have an ssh-agent channel over your connection. With the “-Y” option you’d have X11 forwarding in a channel or multiple channels.) It authenticates the server to the client by showing the human at the terminal a hash of the server’s key and asking them if they recognize it as being correct. (And we all just hit Y without looking. Ha ha. Just kidding.) The client user is authenticated (or not) by using a password, public key, or something else. (You can set up an SSH server to allow anonymous client access. A friend of mine did this on his text BBS; the connections were port forwarding to a telnet port where you’d then log in with a password.)

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

Download wolfSSL Now

We have notified the distros mailing list allowing the member distributions to prepare patches. (No one else gets details about these problems before October 11 without a support contract and a good reason.)

We are cutting the release cycle short and will release curl 8.4.0 on October 11, including fixes for a severity HIGH CVE and one severity LOW. The one rated HIGH is probably the worst curl security flaw in a long time.

The new version and details about the two CVEs will be published around 06:00 UTC on the release day.

• CVE-2023-38545: severity HIGH (affects both libcurl and the curl tool)
• CVE-2023-38546: severity LOW (affects libcurl only, not the tool)

There is no API nor ABI change in the coming curl release.

I cannot disclose any information about which version range that is affected, as that would help identify the problem (area) with a very high accuracy so I cannot do that ahead of time. The “last several years” of versions is as specific as I can get.

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

When it comes to edge computing devices, keeping secrets such as encryption keys or identifiable metadata from being tampered with or stolen is of the utmost importance and the TPM is an ideal facility for keeping such secrets.

WolfTPM already has facilities for storing secrets to the TPM, but we’ve recently added convenience functions for sealing secrets to the TPM using policy authorization tied to PCR values, wolfTPM2_SealWithAuthSig, wolfTPM2_SealWithAuthKey and wolfTPM2_UnsealWithAuthSig. These functions also have NV versions for keeping persistent secrets. wolfTPM2_SealWithAuthSig uses a premade signature to seal the secret instead of a signing key so that the signing key can be kept externally.

Sealing secrets using policy this way not only keeps the secret stored safely within the TPM, but also restricts internal access to the secret, requiring a valid signature of the policyDigest used to seal it and that the PCR value matches the value it had at the time of sealing. This means that an attacker would need the key used to seal the secret and would need to gain access to the system without modifying the PCR values, so tying the PCR values to things like expected log output or the firmware image would lock an attacker out of the secret if those elements were modified.

Try these new functions for yourself with wolfTPM, for examples on how to use these new policy sealing function check out https://github.com/wolfSSL/wolfTPM/tree/master/examples/seal and https://github.com/wolfSSL/wolfTPM/tree/master/examples/nvram.

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

Newly created container for wolfCLU (wolfSSL’s Command Line Utility) was added to wolfSSL’s repo: https://github.com/wolfSSL/wolfssl/tree/master/Docker/wolfCLU The idea is to be able to quickly get set up and start using the latest wolfCLU in your projects. You can get a prebuilt container from https://hub.docker.com/repository/docker/wolfssl/wolfclu/general or by simply running:

docker run -it –rm -v $(pwd):/ws -w /ws wolfssl/wolfclu

This command will run inside your current directory so you can create certificates or verify existing files using wolfCLU.

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

Download wolfSSL Now

Are you part of the Odette automotive networking platform community? Are you already using OFTP? Then we are here to help! As you might know, OFTP requires identity verification via specialized X.509 certificates issued by Odette, but the OFTP protocol depends on the underlying TLS protocol to handle the authentication, encryption and security aspects of the file transfer protocol. The overarching OFTP implementation is usually a separate library from the library that implements TLS. Have you considered using wolfSSL for your TLS and cryptography implementation?

Is your implementation of TLS out of date? Is it even maintained and supported? Do you know if it has any active CVEs against it? Do you need further certifications for your cryptographic implementations such as AUTOSAR? Come talk to us here at wolfSSL; we can help you get your software stack in order!

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

Download wolfSSL Now.

We are thrilled to announce that wolfSSL training webinar is returning on October 5th at 10 AM CET presented by wolfSSL Engineer Daniele. If you are wanting to dive into the insight of wolfSSL embedded SSL/ TLS and expand your knowledge, this is the perfect opportunity.

Watch the training today!
Part 1
Part 2

Daniele will cover topics including library design, the process of building and starting with wolfSSL. He will feature portability, customizability, certificates and keys, SSL debugging and troubleshooting, wolfSSL best practices, and in-depth insights into the wolfCrypt cryptography library.

It is your chance to gain a deep understanding of SSL/ TLS protocols and enhance your knowledge of wolfSSL embedded SSL/ TLS library. Don’t miss this opportunity to gain the crucial knowledge of SSL/ TLS and wolfSSL.

As always, our webinar includes Q&A sessions throughout. 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

Do you have a post-quantum secure-boot requirement from the looming CNSA 2.0 timeline? The timeline has stated that post-quantum signature schemes should be used exclusively by 2030, and adoption should begin immediately. To this end, a few months ago we hinted that plans were underway for post-quantum wolfBoot support, and just recently we added post-quantum LMS/HSS signatures to wolfCrypt.

Building on this, we are excited to announce we have added support for LMS/HSS post-quantum signatures to wolfBoot. LMS wolfBoot support includes keygen, signing, verifying, and importing public keys generated from e.g. an HSM. In fact, to demonstrate HSM interoperability, we recently tested an LMS firmware signature verification integration with Crypto4A’s QxEdge HSM, and showed a live demo at ICMC 2023! If you’re curious, you can read more about our support in our recently added wolfBoot PQ docs, and LMS example config. It describes the LMS/HSS parameters we support from RFC 8554, and the performance tuning and space/time tradeoffs they enable.

LMS/HSS is an example of a post-quantum stateful hash-based signature (HBS) scheme. The security of these signature schemes is based simply on their underlying hash functions and Merkle trees, and does not rely on the assumed mathematical hardness of, for example, prime factorization. This feature gives stateful HBS schemes time tested, tried and true post-quantum security, which is why they have been recommended by NIST SP 800-208 and the NSA’s CNSA 2.0 suite.

An astute reader might notice that both LMS/HSS and XMSS/XMSS^MT were recommended in NIST SP 800-208 and the NSA’s CNSA 2.0 suite. Should we add XMSS/XMSS^MT to wolfBoot as well? Let us know what you think.

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