Category: Uncategorized

wolfSSH version 1.4.6 is now available for download!  Some of the notable changes in this version of wolfSSH are fixes for issues that came about from additional fuzz testing using OSS-Fuzz, improved modularity in the build to assist with resource constrained environments, updates for use with MQX, and expansion of the bundled examples. A full list of the changes can be seen in the ChangeLog.md file bundled with wolfSSH.

If you have any questions or run into any issues, contact us at facts@wolfssl.com, or call us at +1 425 245 8247.

wolfSSL supports embedded customers achieving secure communications in the tightest constraints. For TLS 1.3, this means avoiding certificates and large code size algorithms like RSA and ECC and using Pre-Shared Keys (PSK) with no key exchange.

wolfSSL 4.6.0 has been optimized to be compiled for this configuration only with minimal code and memory usage. This has been achieved by careful exclusion of code across the TLS implementation to only include the parts that are necessary. In fact, the library code can be compiled to less than 50 kB!

If you have any questions or run into any issues, contact us at facts@wolfssl.com, or call us at +1 425 245 8247.

With the newest release of wolfSSL, you can now set the Intel CPU ID flags rather than let them be discovered. The CPU ID flags indicate which instructions are implemented in the CPU. wolfSSL uses this information to decide which is the fastest optimized implementation that will execute!

wolfSSL’s normal discovery works just fine when running on physical CPUs, but emulation in virtual environments does not always report the true state. In these cases users can call cpuid_set_flag() to enable the flag that is needed. Bugs do occur in CPU implementations and in these cases turning off a flag with cpuid_clear_flag() enables switching to different implementations across potentially a number of different cryptographic algorithms. Alternatively, the exact list of flags that you want can be selected with cpuid_select_flags().

If you have any questions or run into any issues, contact us at facts@wolfssl.com, or call us at +1 425 245 8247.

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!

If you have any questions or run into any issues, contact us at facts@wolfssl.com, or call us at +1 425 245 8247.

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:

Architecture: x64	Percent Faster (wolfSSL vs. OpenSSL)
RSA 2048 Sign	8.27%
RSA 2048 Verify	29.75%
ECC P-256 Agree	20.56%
ECC P-256 Sign	25.31%
ECC P-256 Verify	24.13%

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 questions or run into any issues, contact us at facts@wolfssl.com, or call us at +1 425 245 8247.

Don’t miss this exclusive opportunity, 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

Watch the webinar here: Everything about Automotive Security 

See you there!

Additional Resources

If you have any questions or run into any issues, contact us at facts@wolfssl.com, or call us at +1 425 245 8247.

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.

If you have any questions or run into any issues, contact us at facts@wolfssl.com, or call us at +1 425 245 8247.

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.)

	x64	Aarch64
RSA 2048 Sign	32.05%	44.69%
RSA 2048 Verify	21.30%	31.01%
DH 2048 Key Gen	10.90%	16.31%
DH 2048 Agree	6.56%	16.27%
ECC P-256 Key Gen	57.92%	56.95%
ECC P-256 Agree	54.38%	55.90%
ECC P-256 Sign	53.95%	49.95%
ECC P-256 Verify	41.35%	47.73%

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:

x64 (bytes)	TFM	SP Math All
+RSA +DH +ECC	490866	136842	-72.12%
+RSA +DH -ECC	485785	126410	-73.98%
-RSA -DH +ECC	485210	136266	-71.92%

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 questions or run into any issues, contact us at facts@wolfssl.com, or call us at +1 425 245 8247.

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.)

	x64	Aarch64
RSA 2048 Sign	81.43%	50.46%
RSA 2048 Verify	993.81%	522.14%
DH 2048 Key Gen	48.55%	1.82%
DH 2048 Agree	65.16%	12.71%
ECC P-256 Key Gen	45.22%	112.74%
ECC P-256 Agree	43.74%	111.60%
ECC P-256 Sign	55.01%	118.90%
ECC P-256 Verify	62.54%	127.31%

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.

ARM Cortex-M4 (bytes)	Integer	SP Math All
+RSA +DH +ECC	23625	18672	-20.97%
+RSA +DH -ECC	22492	16836	-25.15%
-RSA -DH +ECC	21149	18232	-13.79%

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

If you have any questions or run into any issues, contact us at facts@wolfssl.com, or call us at +1 425 245 8247.

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 WOLFSSL_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:

	Integer	TFM	SP Math All
Number Data	Dynamic	Fixed	Fixed
Memory Usage	Small	Large/Huge	Small/Large/Huge
Speed	Slow	Fast/Very Fast	Slow/Fast/Very Fast
Assembly Code	None	Few Platforms	Many Platforms
Hardened Impls	No	Yes	Yes

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.

If you have any questions or run into any issues, contact us at facts@wolfssl.com, or call us at +1 425 245 8247.