wolfSSL

The wolfSSL embedded SSL library (formerly CyaSSL) is a lightweight SSL/TLS library written in ANSI C and targeted for embedded, RTOS, and resource-constrained environments - primarily because of its small size, speed, and feature set. It is commonly used in standard operating environments as well because of its royalty-free pricing and excellent cross platform support. wolfSSL supports industry standards up to the current TLS 1.3 and DTLS 1.3, is up to 20 times smaller than OpenSSL, and offers progressive ciphers such as ChaCha20, Curve25519, BLAKE2b/BLAKE2s and Post-Quantum TLS 1.3 groups. User benchmarking and feedback reports dramatically better performance when using wolfSSL over OpenSSL. wolfSSL is powered by the wolfCrypt cryptography library. Two versions of wolfCrypt have been FIPS 140-2 validated (Certificate 2425 and certificate 3389). FIPS 140-3 validated (Certificate 4718). For additional information, visit the wolfCrypt FIPS FAQ or contact [email protected]. wolfCrypt also includes support for deriving device-unique keys from hardware entropy ( --enable-puf ). An example exists at SRAM PUF. There are many reasons to choose wolfSSL as your embedded, desktop, mobile, or enterprise SSL/TLS solution. Some of the top reasons include size (typical footprint sizes range from 20-100 kB), support for the newest standards (SSL 3.0, TLS 1.0, TLS 1.1, TLS 1.2, TLS 1.3, DTLS 1.0, DTLS 1.2, and DTLS 1.3), current and progressive cipher support (including stream ciphers), multi-platform, royalty free, and an OpenSSL compatibility API to ease porting into existing applications which have previously used the OpenSSL package. For a complete feature list, see Chapter 4 of the wolfSSL manual. Note 1 wolfSSL as of 3.6.6 no longer enables SSLv3 by default. By default, wolfSSL disables static key cipher suites that use PSK, RSA, or ECDH without ephemeral key exchange. Instead, wolfSSL enables cipher suites that provide perfect forward secrecy (PFS) using ephemeral Diffie-Hellman (DH) or Elliptic Curve (ECC) key exchange, both of which are enabled by default. Important: Static key cipher suites reduce security by eliminating perfect forward secrecy. These cipher suites reuse the same long-term private key for all session key exchanges. In contrast, PFS-enabled cipher suites (the wolfSSL default) generate a new ephemeral key for each session, ensuring that compromising a long-term key cannot decrypt past sessions. When compiling ssl.c , wolfSSL will now issue a compiler error if no cipher suites are available. You can remove this error by defining WOLFSSL ALLOW NO SUITES in the event that you desire that, i.e., you're not using TLS cipher suites. When WOLF CRYPTO CB AES SETKEY is defined, wolfSSL invokes a CryptoCB callback during AES key setup. The callback behavior determines the mode: This feature enables TLS 1.3 traffic key protection on embedded platforms where symmetric keys must never exist in main RAM. Note 2 wolfSSL takes a different approach to certificate verification than OpenSSL does. The default policy for the client is to verify the server, this means that if you don't load CAs to verify the server you'll get a connect error, no signer error to confirm failure (-188). Release 5.9.2 has been developed according to wolfSSL's development and QA process (see link below) and successfully passed the quality criteria. NOTE: The pre-standardization Dilithium API has been renamed to its FIPS 204 ML-DSA name; the legacy dilithium.h header and wc dilithium names remain available through a temporary compatibility shim. The SLH-DSA Hash sign/verify APIs now require a caller-supplied pre-hashed digest rather than the raw message (see Enhancements below). liboqs integrations for ML-KEM, ML-DSA, and SLH-DSA (SPHINCS+) have been removed in favor of the native implementations; the deprecated liblms and libxmss integrations have also been removed. BREAKING (RFC 6960 4.2.2.2) : OCSP responder authorization is now strictly enforced.