RECENT BLOG NEWS

The cryptography world is abuzz with the new proposed NIST standard, Ascon. Earlier this year, NIST selected the Ascon family “for lightweight cryptography applications as it meets the needs of most use cases where lightweight cryptography is required”. More details can be found at the NIST News Update. We at wolfSSL have been testing an initial prototype to have this suite ready for production release as soon as the standard is finalized.

Like all serious, commercial-grade cryptography software, the Ascon implementation is completely open source. Each of the candidate authors has signed a release. 

The Ascon suite contains these 12 algorithms:

• crypto_aead/ascon128v12: Ascon-128
• crypto_aead/ascon128av12: Ascon-128a
• crypto_aead/ascon80pqv12: Ascon-80pq
• crypto_hash/asconhashv12: Ascon-Hash
• crypto_hash/asconhashav12: Ascon-Hasha
• crypto_hash/asconxofv12: Ascon-Xof
• crypto_hash/asconxofav12: Ascon-Xofa
• crypto_auth/asconmacv12: Ascon-Mac
• crypto_auth/asconprfv12: Ascon-Prf
• crypto_auth/asconprfsv12: Ascon-PrfShort

For the full details of the implementation, see: https://ascon.iaik.tugraz.at/files/asconv12-nist.pdf

Part of the requirements of the new lightweight crypto was to be easily implemented in hardware. Of particular interest to hardware implementers is the RTL VHDL source code.

Embedded developers in particular will be very interested in these new algorithms designed specifically to be used on small devices with limited memory and computational resources. Are you an embedded developer? Are you interested in ASCON for 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.

Have you heard the news from the OpenSSL blog?  If you are using the 1.1.1 branch of releases of OpenSSL, come September 11, 2023, there will be no more updates. You can get the details here: 

https://www.openssl.org/blog/blog/2023/03/28/1.1.1-EOL/   

That said, you can breathe a sigh of relief because wolfSSL is here to help.  We have three ways to help.

Compatibility Layer

During the configure step of building wolfSSL, simply use –enable-opensslall and that will turn on our compatibility layer.  Your application build will then have to point to wolfSSL’s include path and binary library file. You should not need to change your source code.  That said, if you find you are getting build errors about missing APIs, please send a message to support@wolfssl.com. We would love to help you keep your code base as clean and simple as possible.

wolfEngine

There are some cases where the compatibility layer might not be appropriate. For example, you might be directly modifying members of OpenSSL’s structures since not all of them are hidden. For such cases, we have wolfEngine. You can continue using OpenSSL, but under the hood the wolfCrypt implementations of the cryptographic algorithms will be used. This might be especially useful if you are looking for an accelerated path to FIPS certification.

wolfProvider

Perhaps you have already gone through the work of migrating to the OpenSSL 3.0.x branches. Noticing any performance issues? Having trouble finding help or getting support? The wolfSSL team is known for having the fastest cryptographic implementations and providing excellent support. Why not try out wolfProvider to see if it can help your project?  Like wolfEngine, if you are looking for an accelerated path to FIPS certification, this might be your solution.No matter your circumstances, we are here to help you through this trying time as OpenSSL ends support for the 1.1.1 series of releases. If you have any questions or run into any issues, contact us at facts@wolfssl.com, or call us at +1 425 245 8247.

If you’re interested in learning more about SSL/TLS or the wolfSSL lightweight SSL library, then you’re in luck. wolfSSL is offering a free 2-day (4 hours each day) training course on wolfSSL.

The next instance of this training course will take place April 19th & 20th from 12:00 PM to 5:00 PM (UTC) both days. This instance was scheduled to accommodate European timezones, soon we will announce an instance that will accommodate Asia time zones.

The course includes Q&A sessions throughout the webinar. To get full access to the course, participants must register for both days. If you’re interested in learning more about SSL/TLS or the wolfSSL library, this training course is an excellent opportunity to deepen your knowledge and skills in this area.

Watch the webinar here: wolfSSL Training Part 1 , wolfSSL Training Part 2

The course objectives are to provide attendees with a basic understanding of how SSL/TLS work, learn the package and design of wolfSSL, effectively build wolfSSL for target platforms, learn effective wolfSSL debugging strategies, add wolfSSL to different client and server applications, learn best practices for adding wolfSSL to embedded, desktop/enterprise, or cloud applications or devices, and develop using wolfSSL’s underlying cryptography library.

If you are working towards CISSP (Certified Information Systems Security Professional) certificate this training webinar could qualify for Group A Credits as a domain related activity. 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 implements support for both client side and server side DTLS. The server side requires extra attention when it comes to Denial-of-Service (DoS) attacks. One way to mitigate DoS on DTLS servers is to operate statelessly until a cookie exchange is completed with the peer. The cookie exchange is implemented in all versions of DTLS. DTLS 1.2 uses a special HelloVerifyRequest message while DTLS 1.3 uses the TLS 1.3 HelloRetryRequest with a cookie extension. The general principle of the cookie exchange is shown in the following figures.

      Client                                   Server
      ------                                   ------
      ClientHello           ------>

                            <----- HelloVerifyRequest
                                   (contains cookie)
      ClientHello           ------>
      (with cookie)

      [Rest of handshake]

Figure 1: DTLS 1.2 cookie exchange (https://www.rfc-editor.org/rfc/rfc6347#section-4.2.1)

      Client                                   Server
      ------                                   ------
      ClientHello           ------>

                            <----- HelloRetryRequest
                                   + cookie
      ClientHello ------>
       + cookie

      [Rest of handshake]

Figure 2: DTLS 1.3 cookie exchange (https://www.rfc-editor.org/rfc/rfc9147.html#section-5.1)

The trick is to parse the initial ClientHello without maintaining state. In wolfSSL release 5.6.0, we implemented parsing the initial ClientHello without maintaining state at all (https://github.com/wolfSSL/wolfssl/pull/5910). Previously, wolfSSL would reset the object when requesting a cookie exchange but this can be unreliable on errors or when new features are implemented. Now we have a dedicated routine to parse the ClientHello statelessly.

wolfSSL also has a callback available when a peer has been verified. To set this callback, use the int wolfDTLS_SetChGoodCb(WOLFSSL* ssl, ClientHelloGoodCb cb, void* user_ctx) API.

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 Inc is proud to announce an important incremental update to wolfSSH: v1.4.13!

In this release, we fix a severe user authentication bug in wolfSSHd. It is highly recommended that anyone using wolfSSHd upgrade to this version immediately (see Vulnerabilities in the change log below).

We have added a STM32Cube Expansion Pack for building in that environment. The daemonization and test coverage of wolfSSHd has been improved. We also improved support for transferring large files with SFTP. We also have a testbed for checking wolfSSH with LwIP using both FreeRTOS and Linux.

The release information from the change log is reposted below:

wolfSSH v1.4.13 (Apr 3, 2023)

New Feature Additions and Improvements

• Improvement to forking the wolfSSHd daemon.
• Added an STM32Cube Expansion pack. See the file _ide/STM32CUBE/README.md_ for more information. (https://www.wolfssl.com/files/ide/I-CUBE-wolfSSH.pack)
• Improved test coverage for wolfSSHd.
• X.509 style private key support.

Fixes

• Fixed shadow password checking in wolfSSHd.
• Building cleanups: warnings, types, 32-bit.
• SFTP fixes for large files.
• Testing and fixes with SFTP and LwIP.

Vulnerabilities

• wolfSSHd would allow users without passwords to log in with any password. This is fixed as of this version. The return value of crypt() was not correctly checked. This issue was introduced in v1.4.11 and only affects wolfSSHd when using the default authentication callback provided with wolfSSHd. Anyone using wolfSSHd should upgrade to v1.4.13.

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

wolfSSH offers all the functionality of a SSH server and client in a compact and microcontroller friendly library and is now available for use as an STM32Cube Package. wolfCrypt, the crypto engine for wolfSSH, heavily supports STM32 hardware and now you can leverage wolfSSH as an SSH solution in the same environment. wolfSSH supports SSH protocol v.2 with both password and public key based authentication and is the easiest way to implement SFTP and SCP on embedded targets, giving the possibility to customize the actions associated with remote filesystem access operations.

Download the new STM32Cube Pack from https://www.wolfssl.com/files/ide/I-CUBE-wolfSSH.pack and follow the documentation here to get started.

You can also reference this webinar for more insight on running wolfSSL on STM32 hardware. How to use wolfSSL software expansion for STM32Cube

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 uses mutexes for most locking synchronization. In release 5.6.0 we have added support for pthread_rwlock_t (https://github.com/wolfSSL/wolfssl/pull/5952 and https://github.com/wolfSSL/wolfssl/pull/6086). It is currently implemented in the session caching logic. This will speed up multi-threaded servers by allowing multiple threads to read from the cache simultaneously. We also recommend multi-threaded servers to define ENABLE_SESSION_CACHE_ROW_LOCK when building wolfSSL. This will initialize and use a separate lock for each row in the cache.

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 makes a great effort to support many different projects. We provide patches for projects to leverage our OpenSSL Compatibility Layer and work with maintainers to upstream support whenever possible. This blog is a list of currently supported open source projects. The support type denotes how wolfSSL is supported. “Patch” means that we provide a patch file that needs to be applied. “Upstream” means that wolfSSL is supported in the project’s mainline. “Fork” means that we provide a forked version of the library with changes made to support wolfSSL.

List of Supported Projects

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 release version 5.6.0 is available now! A couple things to note with this release is that the new and improved ASN parsing, and generation, code is enabled by default now. Additionally we have the upcoming deprecation of –enable-heapmath which is scheduled to be removed by 2024.

This release also saw the addition of DTLS 1.3 stateless ClientHello parsing support. Not only are we leading the pack with adaptation of DTLS 1.3 but we are also adding in features such as the stateless ClientHello support. Some other additions of note were; the port to RT1170 and use of CAAM, update to Stunnel version 5.67, RX64/RX71 hardware acceleration support, and expansion of the compatibility layer.

Improvements to continuous integration testing and some refactoring of our testing framework was done during the last release cycle. To stay the best tested crypto on the market we are constantly trying to improve the testing that we do. This release also had some nice fixes that were made.

A full list of the changes can be found in the ChangeLog.md file bundled with wolfSSL. If you have any questions or run into any issues, contact us at facts@wolfssl.com, or call us at +1 425 245 8247.

What is the difference in modes with wpa_supplicant using wolfSSL FIPS vs non FIPS? Some of the algorithms are restricted when using CONFIG_FIPS=y while building wpa_supplicant. This is not a limitation in wpa_supplicant or in wolfSSL, but is due to restrictions and guidelines put in place for FIPS. To help avoid using algorithms that have not been sanctioned for use with FIPS, the build removes MD5/MD4 along with DES. Removal of these algorithms limits the modes supported.

Another restriction that is seen with FIPS use is that the key passed into HMAC must be 14 bytes or longer, this can cause issues with hunting-and-peck mode unless password sizes can be known to always be large enough. To avoid the limitation on HMAC key size, hash-to-element (sae_pwe=1) can be used instead.

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