RECENT BLOG NEWS

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

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

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.

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:

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.

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.

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 threat of cyber security attacks exist in every industry simply because the need/want of intelligent devices has increased. From the data aspect – we need to address data at rest, data in transit and firmware updates. These three key factors have been wolfSSL’s wheel house for the last 10 years. In the last few years, industries that have safety-critical and/or functional-safety standards are also having to implement Cyber Security Standards; Commercial Aviation (DO-178B/DO-178C) and Automotive (ISO-26262). As we write this blog, these new Cyber Security Industry Standards are still being drafted.

Cyber Security industry standards such as ISO-21434 (Automotive) seems to be somewhat ahead of DO-326A (Airworthiness Security Process Specification) and have kept engineering cyber security teams guessing on how they need to address their architectures and processes. We believe that wolfSSL can help these teams move forward NOW in their planning, coding and implementation because we provide the products that help you meet whatever cyber security process or industry standard you’re trying to meet. Afterall, we do have a DO-178C DAL A certifiable crypto and support FIPS 140-3 today.

Whether you’re trying to address data at rest (SSL/TLS, SSH), data in transit (secure crypto) or firmware updates (SSL/TLS, crypto, MQTT), wolfSSL has a product portfolio that can meet your architecture needs. Our products are dual-licensed for those that need something “Open” or for Commercial use and we support virtually every Operating System and microprocessor on the market. If we don’t support your operating environment we have a world-class engineering team to do so. We even support bare metal!So, don’t wait for standards to be finalized. Don’t wait for a data security breach to be the reason to address cyber security.

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

Users and customers build the wolfSSL embedded SSL/TLS library in all kinds of build environments, one of those being Cygwin on Windows.

To build wolfSSL for Cygwin, here are the current steps to do so. These instructions can also be found in the wolfSSL Manual.

1. Go to https://www.cygwin.com/install.html and download setup-x86_64.exe
2. Run setup-x86_64.exe and install however you choose. Click through the installation menus until you reach the “Select Packages” stage.
3. Click on the “+” icon to expand “All”
4. Now go to the “Archive” section and select “unzip” drop down, change “Skip” to 6.0-15 (or some other version).
5. Under “Devel” click “autoconf” drop down and change “Skip” to “10-1” (or some other version)
6. Under “Devel” click “automake” drop down and change “Skip” to “10-1” (or some other version)
7. Under “Devel” click the “gcc-core” drop down and change “Skip” to 7.4.0-1 (NOTE: wolfSSL has not tested GCC 9 or 10 and as they are fairly new does not recommend using them until they have had a bit more time to be fine-tuned for development).
8. Under “Devel” click the “git” drop down and change “Skip” to 2.29.0-1 (or some other version)
9. Under “Devel” click “libtool” drop down and change “Skip” to “2.4.6-5” (or some other version)
10. Under “Devel” click the “make” drop down and change “Skip” to 4.2.1-1 (or some other version)
11. Click “Next” and proceed through the rest of the installation.

Post Install:

1. Open a Cygwin terminal and clone wolfSSL “git clone https://github.com/wolfssl/wolfssl.git”
2. “cd wolfssl”
3. “./autogen.sh”
4. “./configure”
5. “make”
6. “make check”

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 addition to portable builds, wolfSSL includes TLS 1.3 and has variants available for FIPS 140-2/140-3, DO-178, and MISRA!

Even FPGA softcore microprocessors need security. wolfSSL supports Xilinx MicroBlaze and Altera Nios II as well as Zynq SoCs with acceleration using XilSecure. For new and legacy projects, efficient security is available with first-class support.

See the Xilinx Vitis and Vivado README. For Nios II, from the Quartus developer environment run ./configure --host=nios2-elf

wolfSSL provides leading TLS 1.3 capabilities in a small memory footprint, and also offers FIPS 140-2/140-3 and DO-178 certified versions.

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

FIPS 140-2 requires the use of validated cryptography in the security systems implemented by federal agencies to protect sensitive information. The wolfCrypt Module is a comprehensive suite of FIPS Approved algorithms. All key sizes and modes have been implemented to allow flexibility and efficiency.

The National Institute of Standards and Technology (NIST) is sending FIPS cert #2425 into sunset June 2021. For customers who will be impacted, the wolfCrypt Cryptographic Module maintains its #3389 certificate and can be used in conjunction with the wolfSSL embedded SSL/TLS library for full TLS 1.3 client and server support. Upgrade your FIPS cert with wolfSSL to stay afloat and benefit from: 

• Algorithm support for TLS 1.3!
• New algorithms such as AES (CBC, GCM, CTR, ECB), CVL, Hash DRBG, DSA, DHE, ECDSA (key generation, sign, verify), HMAC, RSA (key generation, sign, verify), SHA-3, SHA-2, SHA-1, and Triple-DES
• Hardware encryption support for NXP’s Cryptographic Assistance and Assurance Module (CAAM), NXP Memory-Mapped Cryptographic Acceleration Unit (mmCAU), Intel’s AES-NI, and more
• Support for secure elements and TPM’s
• Interoperability with wolfBoot, wolfSSH, and wolfTPM
• Integration support for third party libraries such as strongswan, nginx, python and more

Contact us to upgrade to FIPS cert #3389 at fips@wolfssl.com. 

Additional Resources 

Learn more about wolfSSL support for FIPS cert #3389: https://www.wolfssl.com/wolfcrypt-fips-certificate-3389-3/ 

For a list of supported Operating Environments for wolfCrypt FIPS, check our FIPS page: https://www.wolfssl.com/license/fips/ 

Our FIPS Story

wolfSSL is currently the leader in embedded FIPS certificates. We have a long history in FIPS starting with wolfCrypt FIPS 140-2 Level 1 Certificate #2425 as well as wolfCrypt v4 FIPS 140-2 Level 1 Certificate #3389. wolfSSL partners with FIPS experts KeyPair to bring you FIPS consulting services, and high assurance along each step of your FIPS certification process. Additionally, wolfSSL will be the first implementation of FIPS 140-3.

wolfSSL also provides support for a wolfCrypt FIPS Ready version of the library! wolfCrypt FIPS Ready is our FIPS enabled cryptography layer code included in the wolfSSL source tree that you can enable and build. You do not get a FIPS certificate, you are not FIPS approved, but you will be FIPS Ready. FIPS Ready means that you have included the FIPS code into your build and that you are operating according to the FIPS enforced best practices of default entry point, and power on self test.

wolfCrypt FIPS Ready can be downloaded from the wolfSSL download page located here: https://www.wolfssl.com/download/. More information on getting set up with wolfCrypt FIPS Ready can be found in our FIPS Ready User guide here: https://www.wolfssl.com/docs/fips-ready-user-guide/

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

Version 1.7.0 of wolfSSL JNI and JSSE is now available for download! wolfSSL JNI and JSSE provides Java applications with a convenient Java API to the widely-used wolfSSL embedded SSL/TLS library, including support for TLS 1.3!  This package provides both a Java JSSE Provider as well as a thin JNI wrapper around native wolfSSL.

Release 1.7.0 has bug fixes and new features including:

• Fixes for Infer analysis warnings
• Throw exception in DEFAULT_Context creation if engineInit() fails
• Defer creating DEFAULT WolfSSLContext until first use
• Check if Socket is open before doing TLS shutdown in WolfSSLSocket.close()
• Only load X509TrustStore issuers when needed by native wolfSSL verification
• Fix compiler warnings when used with older versions of native wolfSSL
• Verify and load intermediate CA certs in WolfSSLTrustX509.certManagerVerify()
• Add support for setSoTimeout() in WolfSSLSocket
• Fix suites length check in WolfSSLEngineHelper.setLocalCiphers()
• Check for connection closed before completing handshake in SSLSocket.read/write

wolfSSL JNI and JSSE 1.7.0 can be downloaded from the wolfSSL download page and the wolfSSL JNI Manual can be found here.

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