New Hire Announcement

We are thrilled to announce that Mark Minnoch has joined the wolfSSL team. Mark brings more than 20 years of software and systems sales experience in the Networking and Cryptographic Testing industries to wolfSSL.

“Mark is on board at a crucial time to help us respond to the jump in demand for our lightweight, open source embedded SSL/TLS library for securing connections,” said Larry Stefonic, wolfSSL co-founder.

He joins wolfSSL most recently from InfoGard Laboratories, the leading FIPS 140-2 Cryptographic and Security Testing company.  Mark served as a FIPS Security Engineer, Laboratory Director, and Account Manager during his 7+ years at InfoGard. Prior to that, Mark was a Sales Engineer for a network management company.

“I know the challenges in front of IT vendors when they face their first FIPS 140-2 project,” said Mark.  “Now that I am with wolfSSL, I can provide my FIPS expertise to effectively guide IT vendors on the path to their goals.”  

Mark holds a Bachelor of Science Degree in Applied Mathematics from California Polytechnic State University in San Luis Obispo, CA.  He also has CISSP and CISA security certifications.

Notes on Testing wolfSSL

Here at wolfSSL we recently added fuzz testing to our testing processes. Security of CyaSSL software is always on our mind. As the software is used to secure connections and provide software security, the testing of how robust and secure CyaSSL is holds high importance.

As with the halting problem we know it is impossible to test every single possible path through the software but we practice an approach that is focused on lowering risk of failure. In addition to extensive automated tests we also make sure that we specifically test well known use cases. This post outlines some of our testing processes.

1.  Build options:  The first approach we use is by testing combinations of build options. Although there are too many potential combinations to test them all, this approach tests for potential issues with build option compatibility and also allows us to place a confidence value on build option combinations not yet used. We commonly use valgrind and scan-build when testing individual build options.

2.  API testing: In each particular build, we test every available call to cover API uses.

3.  Connection testing and data passing variables: To test this we start with simple connections and data, then as the test progresses we gradually increase the complexity of connection details.

4.  Interop: We test for interoperability with the other open source TLS implementations, including OpenSSL and GnuTLS.

5.  We then test interoperability outside of a closed environment and connect to unknown servers in the real world.

6.  We build with a series of `real` applications, like cURL, wget, pppd, etc.  For some of our customers with top level support, we build the new release with their application.

7. We test using a fuzzing software technique. This bombards the program with invalid, unexpected, and random data that then allows for observing if there is potential memory leaks or logic errors.

8. We engage in another ever expanding universe of benchmark testing, where we look at sizing, transmission rates, connection speeds, etc.

Much of our effort is automated by Jenkins (hat tip to that project!).  Thanks for listening.  If you have specific questions about how we test, please contact us at

CyaSSL and Curve25519

wolfSSL is in the process of adding curve25519 to the CyaSSL lightweight SSL/TLS library. You may ask, why add another ECC curve when CyaSSL already has quite a few ECC options? Curve25519 was chosen because of its record-setting speed while maintaining reliable security. In fact compared with some of the previous ECC curves, Curve25519 actually cuts the time taken to perform in half.

A paper by Daniel Bernstein for farther reading can be found at  If you want more details on our roadmap for Curve25519, contact us at

wolfSSL Tuning Guide Now Available

The wolfSSL Tuning Guide is a reference that allows developers to optimize the performance and memory of the wolfSSL embedded SSL library within their products. The tuning guide includes three recipes for adjusting your wolfSSL implementation to build with minimum footprint, maximum speed, or maximum security. Choosing the correct recipe for building wolfSSL depends on a number of design goals such as the desired security level or memory footprint. These design goals are covered more thoroughly in the tuning guide.

To view these recipes and optimization options for wolfSSL, please view the wolfSSL Tuning Guide on our website. For questions or comments, please email us at

ChaCha20 and Poly1305 AEAD in wolfSSL

We are excited to share our latest enhancement to wolfSSL, which is the addition of ChaCha20 and Poly1305 AEAD cipher suites. Currently they are compatible with the Google server and have the added bonus of also being able to use the more recent ChaCha20 – Poly1305 AEAD constructions.

All that we have left to do with the suites is to be put them through our extensive genetic testing system If you are interested in getting a copy early and beta testing the cipher suites please let us know at, or call us at +1 425 245 8247.