RECENT BLOG NEWS

The wolfSSL embedded SSL/TLS library supports LwIP, the light weight internet protocol implementation, out of the box!  Users should define WOLFSSL_LWIP when compiling wolfSSL, or uncomment the line /* #define WOLFSSL_LWIP */ in wolfssl/wolfcrypt/settings.h to use wolfSSL with LwIP.  This will enable wolfSSL’s LwIP port, which uses LwIP’s BSD socket API.  LwIP users who are using the native LwIP API can also use wolfSSL by defining HAVE_LWIP_NATIVE, then writing and registering their own Input/Output callbacks.

The focus of LwIP is to reduce RAM usage while still providing a full TCP stack.  That focus makes LwIP great for use in embedded systems, the same area where wolfSSL is an ideal match for SSL/TLS needs.  An active community exists with contributor ports for many systems.

In addition to LwIP, wolfSSL also supports TLS 1.3, FIPS 140-2/140-3, DO-178C, and more! For help getting started using wolfSSL in your project, contact wolfSSL at facts@wolfssl.com

In this blog series, we are giving our users more details about wolfSSL‘s new SP Math All math library. So far, we have introduced SP Math All, and provided comparisons to both wolfSSL’s normal Big Integer library and wolfSSL’s TFM library. And up next, what about OpenSSL? Is the SP Math All better than OpenSSL?

When compiling OpenSSL, you will get the highly optimized and large implementations by default. wolfSSL already has the Single Precision code that is as good or better! If you choose to compile OpenSSL without assembly then wolfSSL wins again.

Compiling both with no assembly and the SP Math All fast variation (the smaller of the two fast builds) has the following results:

Better across the aboard! And the size? It is difficult to obtain an accurate number for OpenSSL without writing a custom application. But looking at the size of the BN symbols indicates to us that OpenSSL would be as much as twice the size.

So you can see, the new SP Math All implementation is perfect for all your needs regardless of whether you are developing a memory limited embedded application, other embedded application or a mobile app. And don’t forget that Single Precision implements RSA and ECC algorithms at specific sizes to run blindingly fast in your mobile, desktop or server app and co-exists with SP Math All.

If you have any commentary or feedback please reach out to our team at facts@wolfssl.com or support@wolfssl.com!

Don’t miss this exclusive opportunity, Feb 10 10:00 am Pacific, to gain access to the top thought leaders in the digital space, Ellen Boehm, VP of IoT Strategy at Keyfactor, and Chris Conlon, Engineering Manager at wolfSSL.

Register for the Q&A now to get your questions answered on how to navigate the fast paced world of IoT, and to gain insights on how to embed strong cryptography into vehicles and other connected devices with topics like:

-Unique security challenges that engineers face when securing connected devices
-The role that cryptography plays in securing vehicles
-Practical advice on how these principles can improve security for other connected IoT devices

Register here: (https://hubs.ly/H0Fv3pG0)

See you there!

Additional Resources

Please contact us at facts@wolfssl.com with any questions about the webinar. For technical support, please contact support@wolfssl.com or view our FAQ page.

In the meanwhile, check out the wolfSSL embedded SSL/TLS library, star us on Github, and learn more about the latest TLS 1.3 is available in wolfSSL.

New year new projects!

We are super excited to announce that we are expanding our post-quantum cryptography needs into SSH.

At wolfSSL we try to be progressive with our support of new cryptography technology. To prepare for a post-quantum world where quantum computing presents a threat to public key primitives due to their ability to solve hard cryptographic problems in polynomial time, the National Institute of Standards and Technology (NIST) is currently working on the new generation of quantum-resistant key encapsulation and authentication schemes, especially to address this threat to critical Internet security protocols like the Transfer Layer Security (TLS), and Secure Shell (SSH).

In preparation for the future we are planning for the transition into post quantum cryptography by planning on adding post quantum algorithms in SSH.

The future on the cryptography landscape is scary and exciting. We at wolfSSL Inc want to help you navigate these dangers with cutting edge technologies with quantum computing safe algorithms.

Please visit our website at https://www.wolfssl.com or contact us at facts@wolfssl.com!

In previous blogs, the old math library implementations were discussed and wolfSSL‘s new SP Math All implementation was introduced. Also a comparison between the Integer and SP Math All implementations was discussed showing the improvements in the new library that make it a compelling replacement.

Let’s take a look at how much faster SP Math All is than TFM. (Note: SP Math All configured with –-enable-sp-math-all=huge, TFM configured with --enable-fasthugemath.)

The Elliptic Curve algorithms are consistently faster across the board – about 50% on x64 and Aarch64. The RSA and DH are variable but the RSA sign is significantly faster. This is all due to better multiplication and squaring operations that use better assembly code snippets.

Now for the code size:

The TFM huge build includes Comba implementations of large bit sizes while the SP Math All uses significantly smaller Karatsuba implementations resulting in vast savings in size with increased speed.

Clearly SP Math All has all the features of TFM but does it better!

In the next blog, a comparison of the performance characteristics of SP Math All and OpenSSL. If you have any commentary or feedback please reach out to our team at facts@wolfssl.com or support@wolfssl.com!

We would like to personally invite you to a webinar presented by wolfSSL.

wolfSSL Engineer, Jacob, will talk about the top reasons why people migrate from OpenSSL to wolfSSL as well as how to get started. He will cover how to build with the compatibility layer as well as some examples of applications. Please come with any questions you may have!

When: Feb 4, 2021 08:00 AM Pacific Time (US and Canada)
Topic: Migrating from OpenSSL to wolfSSL

Register in advance for this webinar: https://us02web.zoom.us/webinar/register/WN_77LJw_fbQvWYl3gbiCaFRQ

After registering, you will receive a confirmation email containing information about joining the webinar.

See you there!

Additional Resources

Please contact us at facts@wolfssl.com with any questions about the webinar. For technical support, please contact support@wolfssl.com or view our FAQ page.

In the meanwhile, check out the wolfSSL embedded SSL/TLS library, star us on Github, and learn more about the latest TLS 1.3 is available in wolfSSL.

In our last blog, the multi-precision math implementations in wolfCrypt were discussed with a feature comparison. In this blog we compare the performance of the SP Math All and Integer implementations.

The SP Math All library can be compiled with WOLFSSL_SP_SMALL (--enable-sp-math-all=small) to be small in size, with lower performance, to suit embedded applications. The code is both smaller and faster than the Integer math library.

Let’s take a look at how much faster SP Math All is than Integer. (Note: SP Math All configured with –-enable-sp-math-all=small -–disable-asm C_EXTRA_FLAGS=-DWC_NO_HARDEN, Integer configured with –-disable-fastmath.)

The Elliptic Curve algorithms are consistently faster across the board – about 50% on x64 and 100% on Aarch64. The RSA and DH are variable but the RSA verify operation is much faster due to the optimized exponentiation implementation in SP Math All.

Now, code size is just as important if not more so! Let’s take ARM Cortex M4 as an example.

All builds are smaller with a saving of up to 25% and the code is faster! Similar reductions are seen across all CPUs.

In the next blog, a comparison of the performance characteristics of sp_int.c and tfm.c. If you have any commentary or feedback please reach out to our team at facts@wolfssl.com or support@wolfssl.com!

wolfSSL has a new implementation of the multi-precision math library that is an improvement in every way. The code is in sp_int.c and can be turned on with WOFLSSL_SP_MATH_ALL or -–enable-sp-math-all. Previously the choice was between the implementations in integer.c and tfm.c.

The small or Integer implementation (--disable-fastmath) was written to be simple, to have small code size, and use small amounts of memory. And it does a great job! By using simple, small algorithms and dynamically resizing the memory holding the number the code is perfect for embedded applications. Certain industries have specific coding standards that require no dynamic memory allocation and therefore this implementation is not suitable without the static memory allocator. Also the implementation is not hardened against side-channel attacks. This will not matter for embedded applications that have no cryptographic operations that are externally measurable.

The fast or TFM implementation --enable-fastmath (USE_FAST_MATH), --enable-fasthugemath (USE_FAST_MATH, TFM_SMALL_SET, TFM_HUGE_SET), is based on TomsFastMath – a public domain, large integer arithmetic library. The code was written to be fast. This means the code is more complicated and larger with case specific implementations. Also, the size of data for a number is fixed. Therefore, no dynamic reallocations. The code is hardened against side-channels (TFM_TIMING_RESISTANT) which makes it suitable for wider use. This implementation is perfect for embedded applications with more memory or mobile apps! Basing the implementation on an external code base does have its disadvantages though. Every time we update our code, we drift away from the original and bringing back the external changes takes longer and longer.

So why a new implementation? An implementation that has the best of both worlds – able to be small or fast – and is written from scratch, by us, and maintained, by us, means that we have everything we need in one place. Oh, and did we mention it can be compiled to be smaller and faster than integer.c, or to be smaller and faster than tfm.c?

The new SP Math All (sp_int.c) implementation can be compiled to be small, fast. or very fast and huge. Like the fast implementation, the size of data for a number is fixed and therefore there are no dynamic reallocations. When compiled for small code size, only the simple algorithms for basic operations are included but far less speed is sacrificed! There is also fast implementations that are included with the huge option which include code specifically for larger numbers like 1024-bits and above. To get the code running as fast as possible, snippets of assembly code are used. A wide range of platforms are supported including: x64, x86, Aarch64, ARM32, Cortex-M4, PPC64, PPC, MIPS64, MIPS, RISCV64, RISCV32 and S390X. SP Math All code will use implementations hardened against side-channels by default.

A brief summary of the implementations is below:

In the next blog, we will take a look at the comparison of performance characteristics of SP Math All and Integer implementations. If you have any commentary or feedback, or have questions about using the wolfSSL embedded SSL/TLS library in your project, please reach out to our team at facts@wolfssl.com or support@wolfssl.com!

Starting with version 4.6, wolfCrypt includes full implementations of the XChaCha stream cipher and the XChaCha20-Poly1305 AEAD. This new AEAD supports messages with 64 bit size and immense 192 bit nonces, removing all practical limitations on size and number of messages within a cryptographic session or context. It is ideal for applications such as VPN transports, particularly when a high degree of portability is paramount.

wolfCrypt can process fully authenticated sequences of AEAD messages using a simple one-shot API, via wc_XChaCha20Poly1305_Encrypt() and wc_XChaCha20Poly1305_Decrypt(), or wc_XChaCha20Poly1305_Init() can be called directly to set up the underlying cipher for incremental processing by the existing ChaCha20 and Poly1305 interfaces.

For more information about using wolfSSL or wolfCrypt, or for questions about using wolfSSL in your project, contact us at facts@wolfssl.com.  wolfSSL includes support for TLS 1.3, FIPS 140-2/140-3, DO-178, and more.

We would like to personally invite you to a webinar presented by wolfSSL.

This webinar will provide attendees with the basics and best practices needed to get started using the wolfSSL TLS library in products and projects into 2021! Topics will include a brief overview of TLS 1.3, wolfSSL package structure, how to build wolfSSL, running the wolfCrypt cryptography test and benchmark applications, wolfSSL basic API usage, tips on debugging, and more! Bring your questions for the Q&A session to follow!

When: Jan 27, 2021 09:00 AM Pacific Time (US and Canada)
Topic: Webinar: Getting Started with wolfSSL

Register in advance for this webinar:
https://us02web.zoom.us/webinar/register/WN_8iDFaiW_QSyDIKzyIYXGSA

After registering, you will receive a confirmation email containing information about joining the webinar.

See you there!

Additional Resources

Please contact us at facts@wolfssl.com with any questions about the webinar. For technical support, please contact support@wolfssl.com or view our FAQ page.

In the meanwhile, check out the wolfSSL embedded SSL/TLS library, star us on Github, and learn more about the latest TLS 1.3 is available in wolfSSL.