wolfSSL v5.0.0 Release

    • Happy Fall! wolfSSL has a great treat for all, we released version 5.0.0 and it is now ready for download! This includes a new major feature, having our FIPS 140-3 code added in. Stay tuned for more information in upcoming blog posts regarding the FIPS 140-3 code additions! It also includes notable feature additions such as the post quantum resistant code supporting use of liboqs, expansion to the compatibility layer for ease of replacing OpenSSL and many more features and fixes.

    Key New Feature Additions

    New Product

    • FIPS 140-3 — currently undergoing laboratory testing, code review and ultimately CMVP validation. Targeting the latest FIPS standard.
      • Federal Information Processing Standards (FIPS) 140-3 is a mandatory standard for the protection of sensitive or valuable data within Federal systems. FIPS 140-3 is an incremental advancement of FIPS 140-2, which now standardizes on the ISO 19790:2012 and ISO 24759:2017 specifications.

    Post Quantum

    • Support for OQS‘s (liboqs version 0.7.0) implementation of NIST Round 3 KEMs as TLS 1.3 groups –with-liboqs
    • Hybridizing NIST ECC groups with the OQS groups
    • Remove legacy NTRU and QSH
    • Make quantum-safe groups available to the compatibility layer

    Linux Kernel Module

    • Full support for FIPS 140-3, with in-kernel power on self test (POST) and conditional algorithm self test(s) (CAST)
    • –enable-linuxkm-pie — position-independent in-kernel wolfCrypt container, for FIPS
    • Vectorized x86 acceleration in PK algs (RSA, ECC, DH, DSA) and AES/AES-GCM
    • Vectorized x86 acceleration in interrupt handlers
    • Support for Linux-native module signatures
    • Complete SSL/TLS and Crypto API callable from other kernel module(s)
    • Support for LTS kernel lines: 3.16, 4.4, 4.9, 5.4, 5.10
    • KCAPI: add support for using libkcapi for crypto

    Compatibility Layer Expansion

    The release contained two vulnerabilities – one regarding a hang with DSA sign creation and the other regarding the handling of certificate name constraints. 
    Vulnerabilities

    • [Low] Hang with DSA signature creation when a specific q value is used in a maliciously crafted key. If a DSA key with an invalid q value of either 1 or 0 was decoded and used for creating a signature, it would result in a hang in wolfSSL. Users that are creating signatures with DSA and are using keys supplied from an outside source are affected.
    • [Low] Issue with incorrectly validating a certificate that has multiple subject alternative names when given a name constraint. In the case where more than one subject alternative name is used in the certificate, previous versions of wolfSSL could incorrectly validate the certificate. Users verifying certificates with multiple alternative names and name constraints, are recommended to either use the certificate verify callback to check for this case or update the version of wolfSSL used. Thanks to Luiz Angelo Daros de Luca for the report.

     

    For a full list of changes, check out the updated ChangeLog.md bundled with wolfSSL or view our page on GitHub here (https://github.com/wolfSSL/wolfssl). Any questions can be sent directly to facts@wolfssl.com.