Convert Figma logo to code with AI

wolfSSL logowolfssl

The wolfSSL library is a small, fast, portable implementation of TLS/SSL for embedded devices to the cloud. wolfSSL supports up to TLS 1.3 and DTLS 1.3!

2,395
836
2,395
137
View on GitHub

Top Related Projects

openssl's avatar

openssl

26,357

TLS/SSL and crypto library

Mbed-TLS's avatar

mbedtls

5,654

An open source, portable, easy to use, readable and flexible TLS library, and reference implementation of the PSA Cryptography API. Releases are on a varying cadence, typically around 3 - 6 months between releases.

libressl's avatar

portable

1,380

LibreSSL Portable itself. This includes the build scaffold and compatibility layer that builds portable LibreSSL from the OpenBSD source code. Pull requests or patches sent to tech@openbsd.org are welcome.

google's avatar

boringssl

1,879

Mirror of BoringSSL

aws's avatar

s2n-tls

4,556

An implementation of the TLS/SSL protocols

indutny's avatar

elliptic

1,721

Fast Elliptic Curve Cryptography in plain javascript

Quick Overview

wolfSSL is a lightweight, portable, C-language-based SSL/TLS library targeted for embedded, RTOS, and resource-constrained environments. It's a popular choice for IoT, automotive, and enterprise security applications due to its small footprint, speed, and extensive feature set.

Pros

  • Small footprint (20-100 kB) ideal for embedded systems
  • Fast performance, optimized for speed and efficiency
  • Extensive platform support, including various RTOS and embedded systems
  • Strong security features, including support for the latest TLS 1.3 protocol

Cons

  • Less extensive documentation compared to some larger SSL/TLS libraries
  • Smaller community compared to OpenSSL
  • Some advanced features may require a commercial license
  • Learning curve for developers new to embedded SSL/TLS implementations

Code Examples

  1. Initializing wolfSSL:
#include <wolfssl/ssl.h>

int ret = wolfSSL_Init();
if (ret != WOLFSSL_SUCCESS) {
    // Error handling
}
  1. Creating a wolfSSL context:
WOLFSSL_CTX* ctx = wolfSSL_CTX_new(wolfTLSv1_2_client_method());
if (ctx == NULL) {
    // Error handling
}
  1. Establishing a secure connection:
WOLFSSL* ssl = wolfSSL_new(ctx);
if (ssl == NULL) {
    // Error handling
}

wolfSSL_set_fd(ssl, sockfd);
int ret = wolfSSL_connect(ssl);
if (ret != WOLFSSL_SUCCESS) {
    // Error handling
}

Getting Started

To get started with wolfSSL:

  1. Download the wolfSSL source from GitHub:

    git clone https://github.com/wolfSSL/wolfssl.git

  2. Configure and build the library:

    cd wolfssl
./autogen.sh
./configure
make
sudo make install

  3. Include wolfSSL in your project:

    #include <wolfssl/ssl.h>

  4. Link against the wolfSSL library when compiling:

    gcc -o your_program your_program.c -lwolfssl

Remember to initialize wolfSSL with wolfSSL_Init() at the beginning of your program and clean up with wolfSSL_Cleanup() at the end.

Competitor Comparisons

openssl logo

openssl

26,357

TLS/SSL and crypto library

Pros of OpenSSL

  • Extensive feature set and wide protocol support
  • Large community and extensive documentation
  • Broad platform compatibility and hardware acceleration support

Cons of OpenSSL

  • Larger codebase and memory footprint
  • More complex API and steeper learning curve
  • Slower release cycle for updates and patches

Code Comparison

OpenSSL example (TLS client):

SSL_CTX *ctx = SSL_CTX_new(TLS_client_method());
SSL *ssl = SSL_new(ctx);
SSL_set_fd(ssl, socket);
SSL_connect(ssl);

wolfSSL example (TLS client):

WOLFSSL_CTX* ctx = wolfSSL_CTX_new(wolfTLSv1_2_client_method());
WOLFSSL* ssl = wolfSSL_new(ctx);
wolfSSL_set_fd(ssl, socket);
wolfSSL_connect(ssl);

Both libraries offer similar APIs, but wolfSSL tends to have a more streamlined interface. OpenSSL provides more configuration options, while wolfSSL focuses on a smaller, more efficient codebase. OpenSSL is more widely adopted and has broader protocol support, whereas wolfSSL is designed for embedded systems and resource-constrained environments, offering a smaller footprint and faster performance in many cases.

Mbed-TLS logo

mbedtls

5,654

An open source, portable, easy to use, readable and flexible TLS library, and reference implementation of the PSA Cryptography API. Releases are on a varying cadence, typically around 3 - 6 months between releases.

Pros of Mbed TLS

  • More extensive documentation and examples
  • Broader platform support, including bare-metal environments
  • Easier integration with ARM-based systems and IoT devices

Cons of Mbed TLS

  • Generally slower performance compared to wolfSSL
  • Larger code size and memory footprint
  • Less frequent updates and slower adoption of new standards

Code Comparison

Mbed TLS initialization:

#include "mbedtls/ssl.h"

mbedtls_ssl_context ssl;
mbedtls_ssl_config conf;

mbedtls_ssl_init(&ssl);
mbedtls_ssl_config_init(&conf);

wolfSSL initialization:

#include <wolfssl/ssl.h>

WOLFSSL_CTX* ctx;
WOLFSSL* ssl;

ctx = wolfSSL_CTX_new(wolfTLSv1_2_client_method());
ssl = wolfSSL_new(ctx);

Both libraries offer similar APIs for SSL/TLS functionality, but wolfSSL tends to have a more streamlined approach with fewer function calls required for basic setup. Mbed TLS provides more granular control over configuration options, which can be beneficial for complex scenarios but may require more code for simple use cases.

libressl logo

portable

1,380

LibreSSL Portable itself. This includes the build scaffold and compatibility layer that builds portable LibreSSL from the OpenBSD source code. Pull requests or patches sent to tech@openbsd.org are welcome.

Pros of LibreSSL

  • More comprehensive and feature-rich, offering a wider range of cryptographic functions
  • Better compatibility with OpenSSL, making it easier to integrate into existing systems
  • More active development and frequent updates

Cons of LibreSSL

  • Larger codebase and memory footprint, which may not be ideal for embedded systems
  • Potentially slower performance due to its more extensive feature set
  • Less focus on small-scale or resource-constrained environments

Code Comparison

LibreSSL:

SSL_CTX *ctx = SSL_CTX_new(TLS_method());
SSL_CTX_set_min_proto_version(ctx, TLS1_2_VERSION);
SSL_CTX_set_max_proto_version(ctx, TLS1_3_VERSION);

wolfSSL:

WOLFSSL_CTX* ctx = wolfSSL_CTX_new(wolfTLSv1_2_client_method());
wolfSSL_CTX_SetMinVersion(ctx, WOLFSSL_TLSV1_2);
wolfSSL_CTX_SetMaxVersion(ctx, WOLFSSL_TLSV1_3);

Both libraries provide similar functionality for creating SSL contexts and setting protocol versions. However, LibreSSL's API more closely resembles OpenSSL, while wolfSSL uses its own naming conventions.

google logo

boringssl

1,879

Mirror of BoringSSL

Pros of BoringSSL

  • Developed and maintained by Google, benefiting from their extensive resources and expertise
  • Designed for performance and efficiency in modern systems
  • Regularly updated with the latest security patches and improvements

Cons of BoringSSL

  • Less flexible and customizable compared to wolfSSL
  • Not as widely supported across different platforms and architectures
  • May have a steeper learning curve for developers unfamiliar with Google's coding practices

Code Comparison

wolfSSL:

int wolfSSL_CTX_use_certificate_file(WOLFSSL_CTX* ctx, const char* file,
                                     int format)
{
    WOLFSSL_ENTER("wolfSSL_CTX_use_certificate_file");
    return ProcessFile(ctx, file, format, CERT_TYPE, NULL, 0, NULL);
}

BoringSSL:

int SSL_CTX_use_certificate_file(SSL_CTX *ctx, const char *file, int type) {
  BIO *in;
  int ret = 0;
  X509 *x = NULL;

  in = BIO_new(BIO_s_file());
  if (in == NULL) {
    OPENSSL_PUT_ERROR(SSL, ERR_R_BUF_LIB);
    goto end;
  }

Both libraries provide similar functionality for loading certificates, but BoringSSL's implementation is more verbose and includes additional error handling.

aws logo

s2n-tls

4,556

An implementation of the TLS/SSL protocols

Pros of s2n-tls

  • Designed specifically for AWS services, offering seamless integration with AWS infrastructure
  • Focused on simplicity and minimal code base, potentially reducing the attack surface
  • Regularly audited and maintained by AWS, ensuring high security standards

Cons of s2n-tls

  • Limited to TLS 1.2 and 1.3, lacking support for older protocols
  • Fewer cryptographic algorithms and features compared to wolfSSL
  • Less flexibility for customization and integration with non-AWS systems

Code Comparison

s2n-tls:

s2n_config *config = s2n_config_new();
s2n_connection *conn = s2n_connection_new(S2N_CLIENT);
s2n_connection_set_config(conn, config);
s2n_negotiate(conn, &blocked);

wolfSSL:

WOLFSSL_CTX* ctx = wolfSSL_CTX_new(wolfTLSv1_2_client_method());
WOLFSSL* ssl = wolfSSL_new(ctx);
wolfSSL_connect(ssl);
wolfSSL_write(ssl, message, strlen(message));

Both libraries offer straightforward APIs for establishing TLS connections, but s2n-tls focuses on AWS-specific use cases, while wolfSSL provides a more general-purpose solution with broader protocol support and customization options.

indutny logo

elliptic

1,721

Fast Elliptic Curve Cryptography in plain javascript

Pros of elliptic

  • Lightweight and focused specifically on elliptic curve cryptography
  • Easier to integrate into JavaScript/Node.js projects
  • More active community contributions and frequent updates

Cons of elliptic

  • Limited to elliptic curve operations, not a full cryptographic suite
  • Less comprehensive documentation compared to wolfSSL
  • May have lower performance for certain operations on some platforms

Code Comparison

elliptic:

const EC = require('elliptic').ec;
const ec = new EC('secp256k1');
const key = ec.genKeyPair();
const signature = key.sign(msgHash);
console.log(signature.toDER('hex'));

wolfSSL:

#include <wolfssl/options.h>
#include <wolfssl/wolfcrypt/ecc.h>

ecc_key key;
wc_ecc_init(&key);
wc_ecc_make_key(&rng, 32, &key);
wc_ecc_sign_hash(hash, hashLen, signature, &sigLen, &rng, &key);

wolfSSL offers a more comprehensive cryptographic library with support for various algorithms and protocols, while elliptic focuses specifically on elliptic curve operations. elliptic is more suitable for JavaScript-based projects, whereas wolfSSL is better for C/C++ applications requiring a full-featured cryptographic suite.

Convert Figma logo designs to code with AI

Visual Copilot

Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.

Try Visual Copilot

README

wolfSSL Embedded SSL/TLS Library

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 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 fips@wolfssl.com.

Why Choose wolfSSL?

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.

Notes, Please Read

Note 1

wolfSSL as of 3.6.6 no longer enables SSLv3 by default. wolfSSL also no longer supports static key cipher suites with PSK, RSA, or ECDH. This means if you plan to use TLS cipher suites you must enable DH (DH is on by default), or enable ECC (ECC is on by default), or you must enable static key cipher suites with one or more of the following defines:

WOLFSSL_STATIC_DH
WOLFSSL_STATIC_RSA
WOLFSSL_STATIC_PSK

Though static key cipher suites are deprecated and will be removed from future versions of TLS. They also lower your security by removing PFS.

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.

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

If you want to mimic OpenSSL behavior of having SSL_connect succeed even if verifying the server fails and reducing security you can do this by calling:

wolfSSL_CTX_set_verify(ctx, WOLFSSL_VERIFY_NONE, NULL);

before calling wolfSSL_new();. Though it's not recommended.

Note 3

The enum values SHA, SHA256, SHA384, SHA512 are no longer available when wolfSSL is built with --enable-opensslextra (OPENSSL_EXTRA) or with the macro NO_OLD_SHA_NAMES. These names get mapped to the OpenSSL API for a single call hash function. Instead the name WC_SHA, WC_SHA256, WC_SHA384 and WC_SHA512 should be used for the enum name.

wolfSSL Release 5.7.6 (Dec 31, 2024)

Release 5.7.6 has been developed according to wolfSSL's development and QA process (see link below) and successfully passed the quality criteria. https://www.wolfssl.com/about/wolfssl-software-development-process-quality-assurance

NOTE:

  • --enable-heapmath is deprecated.
  • In this release, the default cipher suite preference is updated to prioritize TLS_AES_256_GCM_SHA384 over TLS_AES_128_GCM_SHA256 when enabled.
  • This release adds a sanity check for including wolfssl/options.h or user_settings.h.

PR stands for Pull Request, and PR references a GitHub pull request number where the code change was added.

Vulnerabilities

  • [Med] An OCSP (non stapling) issue was introduced in wolfSSL version 5.7.4 when performing OCSP requests for intermediate certificates in a certificate chain. This affects only TLS 1.3 connections on the server side. It would not impact other TLS protocol versions or connections that are not using the traditional OCSP implementation. (Fix in pull request 8115)

New Feature Additions

  • Add support for RP2350 and improve RP2040 support, both with RNG optimizations (PR 8153)
  • Add support for STM32MP135F, including STM32CubeIDE support and HAL support for SHA2/SHA3/AES/RNG/ECC optimizations. (PR 8223, 8231, 8241)
  • Implement Renesas TSIP RSA Public Enc/Private support (PR 8122)
  • Add support for Fedora/RedHat system-wide crypto-policies (PR 8205)
  • Curve25519 generic keyparsing API added with wc_Curve25519KeyToDer and wc_Curve25519KeyDecode (PR 8129)
  • CRL improvements and update callback, added the functions wolfSSL_CertManagerGetCRLInfo and wolfSSL_CertManagerSetCRLUpdate_Cb (PR 8006)
  • For DTLS, add server-side stateless and CID quality-of-life API. (PR 8224)

Enhancements and Optimizations

  • Add a CMake dependency check for pthreads when required. (PR 8162)
  • Update OS_Seed declarations for legacy compilers and FIPS modules (boundary not affected). (PR 8170)
  • Enable WOLFSSL_ALWAYS_KEEP_SNI by default when using --enable-jni. (PR 8283)
  • Change the default cipher suite preference, prioritizing TLS_AES_256_GCM_SHA384 over TLS_AES_128_GCM_SHA256. (PR 7771)
  • Add SRTP-KDF (FIPS module v6.0.0) to checkout script for release bundling (PR 8215)
  • Make library build when no hardware crypto available for Aarch64 (PR 8293)
  • Update assembly code to avoid uint*_t types for better compatibility with older C standards. (PR 8133)
  • Add initial documentation for writing ASN template code to decode BER/DER. (PR 8120)
  • Perform full reduction in sc_muladd for EdDSA with Curve448 (PR 8276)
  • Allow SHA-3 hardware cryptography instructions to be explicitly not used in MacOS builds (PR 8282)
  • Make Kyber and ML-KEM available individually and together. (PR 8143)
  • Update configuration options to include Kyber/ML-KEM and fix defines used in wolfSSL_get_curve_name. (PR 8183)
  • Make GetShortInt available with WOLFSSL_ASN_EXTRA (PR 8149)
  • Improved test coverage and minor improvements of X509 (PR 8176)
  • Add sanity checks for configuration methods, ensuring the inclusion of wolfssl/options.h or user_settings.h. (PR 8262)
  • Enable support for building without TLS (NO_TLS). Provides reduced code size option for non-TLS users who want features like the certificate manager or compatibility layer. (PR 8273)
  • Exposed get_verify functions with OPENSSL_EXTRA. (PR 8258)
  • ML-DSA/Dilithium: obtain security level from DER when decoding (PR 8177)
  • Implementation for using PKCS11 to retrieve certificate for SSL CTX (PR 8267)
  • Add support for the RFC822 Mailbox attribute (PR 8280)
  • Initialize variables and adjust types resolve warnings with Visual Studio in Windows builds. (PR 8181)
  • Refactors and expansion of opensslcoexist build (PR 8132, 8216, 8230)
  • Add DTLS 1.3 interoperability, libspdm and DTLS CID interoperability tests (PR 8261, 8255, 8245)
  • Remove trailing error exit code in wolfSSL install setup script (PR 8189)
  • Update Arduino files for wolfssl 5.7.4 (PR 8219)
  • Improve Espressif SHA HW/SW mutex messages (PR 8225)
  • Apply post-5.7.4 release updates for Espressif Managed Component examples (PR 8251)
  • Expansion of c89 conformance (PR 8164)
  • Added configure option for additional sanity checks with --enable-faultharden (PR 8289)
  • Aarch64 ASM additions to check CPU features before hardware crypto instruction use (PR 8314)

Fixes

  • Fix a memory issue when using the compatibility layer with WOLFSSL_GENERAL_NAME and handling registered ID types. (PR 8155)
  • Fix a build issue with signature fault hardening when using public key callbacks (HAVE_PK_CALLBACKS). (PR 8287)
  • Fix for handling heap hint pointer properly when managing multiple WOLFSSL_CTX objects and free’ing one of them (PR 8180)
  • Fix potential memory leak in error case with Aria. (PR 8268)
  • Fix Set_Verify flag behaviour on Ada wrapper. (PR 8256)
  • Fix a compilation error with the NO_WOLFSSL_DIR flag. (PR 8294)
  • Resolve a corner case for Poly1305 assembly code on Aarch64. (PR 8275)
  • Fix incorrect version setting in CSRs. (PR 8136)
  • Correct debugging output for cryptodev. (PR 8202)
  • Fix for benchmark application use with /dev/crypto GMAC auth error due to size of AAD (PR 8210)
  • Add missing checks for the initialization of sp_int/mp_int with DSA to free memory properly in error cases. (PR 8209)
  • Fix return value of wolfSSL_CTX_set_tlsext_use_srtp (8252)
  • Check Root CA by Renesas TSIP before adding it to ca-table (PR 8101)
  • Prevent adding a certificate to the CA cache for Renesas builds if it does not set CA:TRUE in basic constraints. (PR 8060)
  • Fix attribute certificate holder entityName parsing. (PR 8166)
  • Resolve build issues for configurations without any wolfSSL/openssl compatibility layer headers. (PR 8182)
  • Fix for building SP RSA small and RSA public only (PR 8235)
  • Fix for Renesas RX TSIP RSA Sign/Verify with wolfCrypt only (PR 8206)
  • Fix to ensure all files have settings.h included (like wc_lms.c) and guards for building all *.c files (PR 8257 and PR 8140)
  • Fix x86 target build issues in Visual Studio for non-Windows operating systems. (PR 8098)
  • Fix wolfSSL_X509_STORE_get0_objects to handle no CA (PR 8226)
  • Properly handle reference counting when adding to the X509 store. (PR 8233)
  • Fix for various typos and improper size used with FreeRTOS_bind in the Renesas example. Thanks to Hongbo for the report on example issues. (PR 7537)
  • Fix for potential heap use after free with wolfSSL_PEM_read_bio_PrivateKey. Thanks to Peter for the issue reported. (PR 8139)

For additional vulnerability information visit the vulnerability page at: https://www.wolfssl.com/docs/security-vulnerabilities/

See INSTALL file for build instructions. More info can be found on-line at: https://wolfssl.com/wolfSSL/Docs.html

Resources

wolfSSL Website

wolfSSL Wiki

FIPS 140-2/140-3 FAQ

wolfSSL Documentation

wolfSSL Manual

wolfSSL API Reference

wolfCrypt API Reference

TLS 1.3

wolfSSL Vulnerabilities

Additional wolfSSL Examples

Directory structure

<wolfssl_root>
├── certs   [Certificates used in tests and examples]
├── cmake   [Cmake build utilities]
├── debian  [Debian packaging files]
├── doc     [Documentation for wolfSSL (Doxygen)]
├── Docker  [Prebuilt Docker environments]
├── examples    [wolfSSL examples]
│   ├── asn1    [ASN.1 printing example]
│   ├── async   [Asynchronous Cryptography example]
│   ├── benchmark   [TLS benchmark example]
│   ├── client  [Client example]
│   ├── configs [Example build configurations]
│   ├── echoclient  [Echoclient example]
│   ├── echoserver  [Echoserver example]
│   ├── pem [Example for convert between PEM and DER]
│   ├── sctp    [Servers and clients that demonstrate wolfSSL's DTLS-SCTP support]
│   └── server  [Server example]
├── IDE     [Contains example projects for various development environments]
├── linuxkm [Linux Kernel Module implementation]
├── m4      [Autotools utilities]
├── mcapi   [wolfSSL MPLAB X Project Files]
├── mplabx  [wolfSSL MPLAB X Project Files]
├── mqx     [wolfSSL Freescale CodeWarrior Project Files]
├── rpm     [RPM packaging metadata]
├── RTOS
│   └── nuttx   [Port of wolfSSL for NuttX]
├── scripts [Testing scripts]
├── src     [wolfSSL source code]
├── sslSniffer  [wolfSSL sniffer can be used to passively sniff SSL traffic]
├── support [Contains the pkg-config file]
├── tests   [Unit and configuration testing]
├── testsuite   [Test application that orchestrates tests]
├── tirtos  [Port of wolfSSL for TI RTOS]
├── wolfcrypt   [The wolfCrypt component]
│   ├── benchmark   [Cryptography benchmarking application]
│   ├── src         [wolfCrypt source code]
│   │   └── port    [Supported hardware acceleration ports]
│   └── test        [Cryptography testing application]
├── wolfssl [Header files]
│   ├── openssl [Compatibility layer headers]
│   └── wolfcrypt   [Header files]
├── wrapper [wolfSSL language wrappers]
└── zephyr  [Port of wolfSSL for Zephyr RTOS]