Category: Uncategorized

We are delighted to announce that the creator of cURL, Daniel Stenberg, will be hosting a libcurl training webinar in November. Libcurl is a free and user-friendly client-side URL transfer library that supports various protocols, including DICT, FILE, FTP, and FTPS, making it one of the most outstanding and widely used libraries for URL-based data transfer.

During the libcurl training webinar, you will have the opportunity to dive deep into libcurl and gain a comprehensive understanding of its applications. Daniel will showcase best practices and various use cases for libcurl, demonstrating how to utilize it in applications.

More details about the webinar will be provided soon, so please keep an eye out for updates. This promises to be one of the most exclusive events of the year, and it’s an opportunity you won’t want to miss.

For the latest updates and exclusive content, be sure to follow us on Twitter. You’ll be the first to receive updates about the webinar, ensuring you stay informed and prepared for this exciting event.

Get ready to learn and enhance your skill sets with Daniel Stenberg in November!

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

If you follow us at wolfSSL, you’ll know we’re excited about post-quantum cryptography. For example, our recent DTLS 1.3 implementation supports post-quantum KEMs and signatures, and we just added support for post-quantum LMS/HSS signatures to wolfCrypt and wolfBoot. The latter was motivated particularly by the NSA’s CNSA 2.0 suite timeline, which specifies that adoption of stateful hash-based signature schemes (the kind recommended in NIST SP 800-208) should begin immediately. These signature schemes are valuable because they combine small public keys with relatively fast signing and verifying, and their signature sizes and key generation times are tunable via their different parameters.

You probably also know that both XMSS/XMSS^MT and LMS/HSS were recommended in NIST SP 800-208 and the NSA’s CNSA 2.0 suite. Hence, we are pleased to announce we are adding support for XMSS/XMSS^MT signatures to wolfCrypt, which will be accomplished by experimental integration with the xmss-reference implementation for RFC8391, similar to our previous post-quantum integrations with libOQS and hash-sigs LMS/HSS. You can read more about it in these XMSS pull request links:

• https://github.com/wolfSSL/wolfssl/pull/6840
• https://github.com/wolfSSL/wolfssl-examples/pull/403
• https://github.com/wolfSSL/documentation/pull/110

Our XMSS integration relies on a patch to xmss-reference that allows it to offload SHA operations to wolfCrypt, and thus allows it to leverage the same cryptographic hardware acceleration as wolfCrypt. The speedups improve performance for key generation, signing, and verifying. Another detail you might have noticed in our patch is that it includes wolfBoot XMSS support – for more information on that, please stay tuned!

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

Download wolfSSL Now

ExpressVPN has merged DTLS 1.3 support into their lightway-core library. This is the library that implements their modern Lightway VPN protocol. Lightway is a new protocol and built from the ground up with privacy, security, speed, and reliability in mind. Currently it depends on DTLS 1.2 and TLS 1.3 but with the addition of DTLS 1.3, it opens up a whole new set of possibilities. Lightway will be able to push what is possible in every aspect. The pull request implements new DTLS 1.3 API’s from wolfSSL.

wolfSSL is the first TLS library to adopt and implement DTLS 1.3. DTLS 1.3 has many improvements over DTLS 1.2 in areas of security and reliability. One of the biggest and most important changes is the addition of acknowledgements to the protocol. In DTLS 1.2, when a peer has detected a network failure (for example a packet was dropped or a timeout has been reached) it had no choice but to resend the entirety of its previous flight. In DTLS 1.3, the peer can just send a minimal acknowledgement packet that also specifies exactly which messages it is missing. It cuts down drastically on how much data has to be transmitted and saves both peers from having to resend entire flights if just a part is missing.

Another advantage of DLTS 1.3 over DTLS 1.2 is that it is based on the TLS 1.3 protocol. TLS 1.3 is currently receiving many exciting new additions and all this work benefits DTLS 1.3 as well. Post-quantum cryptography (PQC) ciphersuites are actively being researched in TLS 1.3 and it is unlikely they will be backported to TLS 1.2. DTLS 1.3 benefits from this research and wolfSSL can support arbitrarily large PQC keys in DTLS 1.3! One more example is the Encrypted Client Hello (ECH) which makes the connection fully private by not leaking any sensitive information (like the Server Name Indication extension) in plaintext. For a full description, please take a look at our ECH feature announcement.

DTLS 1.3 also benefits from the filtered list of available ciphers. Legacy and deprecated algorithms have been removed from the protocol and are no longer supported. All the ciphers are AEAD ciphers that provide increased security and performance.

For a full discussion of the differences between DTLS 1.2 and DTLS 1.3 please see our analysis blog. For any questions regarding DTLS 1.3 and wolfSSL please contact us at facts@wolfSSL.com or call us at +1 425 245 8247.

Download wolfSSL Now

wolfSSL and CodeSecure are partnering to host a webinar on October 19th at 10 AM PT, discussing the significance of testing in embedded software. wolfSSL Engineer Andras and CodeSecure VP of Global Solutions Engineering, Mark, will discuss how each company processes testing to deliver safe and secure embedded software that requires a rigorous focus on automated testing.

Watch the webinar here: The Power of Testing in Embedded Software

You will gain insights into how wolfSSL will proceed with their testing mandate and how their focus on testing allows them to innovate with high quality, portable, embedded security software. CodeSecure will explain how Static Application Security Testing (SAST) is a crucial pillar in any automated testing workflow and how CodeSonar can be used both in developer pipelines as well as in daily testing cycles to find problems that dynamic testing may miss. Additionally, this webinar will review a few examples of defects that CodeSonar has detected and that were recently fixed in wolfSSL.

This is your opportunity to learn about the importance of testing in embedded software and uncover the secrets behind high-quality software from two industry-leading companies.

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

wolfSSL makes a great effort to support a variety of open-source projects and the latest addition to the list is the disk encryption utility, VeraCrypt. With our recent porting effort, users will be able to leverage the VeraCrypt application with our cutting-edge crypto library, wolfCrypt.

VeraCrypt is packed with highly customizable security features employed to create and mount encrypted virtual disks as real disks, in addition to supporting entire/partial partition encryption and hidden volumes. Plugging wolfCrypt into the project makes VeraCrypt the ideal solution for users with performance and FIPS validation requirements.

Follow the instructions here to set up VeraCrypt with wolfCrypt.

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

Here at wolfSSL, we’ve got a new product that should interest you! We love it when we can help make potentially painful decisions easier for our customers.

Have you switched over to the 3.x series of releases on OpenSSL? It was likely a very large investment in time and human resources, but you needed to because the 1.1.1 series of releases recently went EOL (End of Life) in early September. Congratulations if you successfully completed your migration.

If after that migration you suddenly have a new FIPS 140-3 requirement, you’re probably wondering what a FIPS canister is going to look like for the the 3.x series of releases of OpenSSL. You’re likely aware that they are no longer supporting the “engine” interface and have moved to the “provider” model. There is a fips-provider, but if you look at the documentation you’ll note that it only provides FIPS 140-2. What about FIPS 140-3? Unfortunately, there is no support for it. When will OpenSSL’s certification for FIPS-140-3 be ready? No one knows; not even the OpenSSL Team.

What about wolfSSL? Our wolfCrypt FIPS product is right on the cusp of being granted FIPS 140-3 certification. How does that help you? Well, we have a wolfProvider product that provides the glue between OpenSSL 3.x series of releases and wolfCrypt FIPS. To use wolfProvider and wolfCrypt FIPS you don’t even need to recompile OpenSSL nor your applications. Just specify where wolfProvider is located via configuration file, install the wolfssl library to the default system location and you’re good to go!

Go ahead and take it for a spin! You can find wolfCrypt FIPS as part of the wolfssl fips-ready release which you can download and wolfProvider in its github repo all under GPL licensing terms until you want to use it for commercial purposes.

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

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