Files
Tobias Frauenschläger 9393d62591 Replace liboqs SPHINCS+ with SLH-DSA in certificate layer
Replace the liboqs-based pre-standardization SPHINCS+ implementation
with the native FIPS 205 SLH-DSA implementation across the
certificate / ASN.1 / X.509 layers, and add SLH-DSA-rooted test
certificates plus TLS 1.3 .conf scenarios that exercise the new
verification path. All liboqs SPHINCS+ code is removed.

This enables SLH-DSA for certificate chain authentication: CA
certificates signed with SLH-DSA, certificate signature verification
against an SLH-DSA root. TLS 1.3 entity authentication via
CertificateVerify with SLH-DSA will be added in a follow-up PR.

Follows RFC 9909 (X.509 Algorithm Identifiers for SLH-DSA) and
NIST FIPS 205. Supports both SHAKE and SHA-2 parameter families
across all twelve standardized variants.

DER codec:
- New PrivateKeyDecode, PublicKeyDecode, KeyToDer, PrivateKeyToDer,
  PublicKeyToDer with RFC 9909 encoding (bare OCTET STRING containing
  4*n raw bytes = SK.seed || SK.prf || PK.seed || PK.root, no nested
  wrapper). OID auto-detection across all twelve SHAKE / SHA-2 variants.
- PublicKeyDecode raw-bytes fast path mirrors wc_Falcon_PublicKeyDecode
  and wc_Dilithium_PublicKeyDecode so callers (notably
  wolfssl_x509_make_der and ConfirmSignature, which pass the raw
  BIT STRING contents stashed by StoreKey) decode correctly. Honours
  the caller's *inOutIdx start offset.
- Error paths in Private/PublicKeyDecode preserve params/flags/
  inOutIdx and only ForceZero the buffer half each helper actually
  writes; skip the wipe entirely on BAD_LENGTH_E (no bytes touched).
- ImportPublic uses |= on flags so a Private-then-Public import
  sequence retains FLAG_PRIVATE.

OID dispatch:
- 12 standardized NIST OIDs (6 SHAKE + 6 SHA-2) per RFC 9909. The
  pre-standardization OID-collision mechanism is removed since NIST
  OIDs do not collide.
- wc_SlhDsaOidToParam / wc_SlhDsaOidToCertType return NOT_COMPILED_IN
  (rather than -1) for recognised SLH-DSA OIDs whose parameter set
  isn't built; wc_IsSlhDsaOid recognises both. The x509 dispatch
  surfaces this as a precise diagnostic instead of the generic
  "No public key found".
- wc_GetKeyOID picks a placeholder parameter from whatever variant is
  compiled in and #errors at compile time if none is.
- asn_orig.c EncodeCert / EncodeCertReq accept SHA-2 SLH-DSA keyTypes
  alongside SHAKE.

Tests and fixtures:
- Test cert chain in certs/slhdsa/: SLH-DSA-SHAKE-128s and
  SLH-DSA-SHA2-128s self-signed roots that sign reused ML-DSA-44
  entity keys (server + client), plus the gen script
  (gen-slhdsa-mldsa-certs.sh, OpenSSL >= 3.5).
- New TLS 1.3 .conf scenarios under tests/suites.c dispatch:
  test-tls13-slhdsa-shake.conf, test-tls13-slhdsa-sha2.conf, and a
  wrong-CA negative test test-tls13-slhdsa-fail.conf.
- DER round-trip and on-disk decode tests; bench_slhdsa_*_key.der
  fixtures regenerated with wolfSSL's own encoder so the codec is
  pinned to RFC 9909.
- New unit test test_wc_slhdsa_x509_i2d_roundtrip exercises the raw
  PublicKeyDecode entry point that wolfssl_x509_make_der relies on.
- test_wc_slhdsa_check_key now tests both Public-then-Private and
  Private-then-Public import orderings.

Build / ABI:
- DYNAMIC_TYPE_SPHINCS = 98 kept as RESERVED with a tombstone comment
  for ABI stability; new code should use DYNAMIC_TYPE_SLHDSA (107).
- All build system / IDE project files updated; SPHINCS+ sources,
  headers, and test data removed.
- Dead bench_slhdsa_*_key arrays removed from gencertbuf.pl and
  certs_test.h; the .der files on disk drive the decode tests.
2026-04-30 18:32:07 +02:00
..
2026-02-18 09:52:21 -07:00
2026-02-18 09:52:21 -07:00
2025-07-10 16:11:36 -06:00

wolfSSL Espressif Component

This is the directory for wolfSSL as an Espressif ESP-IDF component.

Other options are available, such as installing wolfSSL as a local project component using the Managed Component.

Enabling this wolfSSL ESP-IDF component allows other ESP-IDF libraries such as those that depend on ESP-TLS to also use the wolfSSL library. (See github.com/wolfSSL/wolfssl)

The wolfSSL source code is not included here. Instead, the idf.py menuconfig option can be used to configure the sdkconfig file setting: CONFIG_CUSTOM_SETTING_WOLFSSL_ROOT to point to the desired wolfSSL code.

Directory Contents

This directory must contain, at a minimum:

  • CMakeLists.txt
  • ./include/user_settings.h

The directory should also contain:

  • Kconfig
  • component.mk

The directory may contain wolfSSL source, for example with a Managed Component, or if the setup.sh script was used from wolfSSL/IDE/Espressif/ESP-IDF.

Under normal circumstances when the wolfSSL source is not included here, the CMakeLists.txt will search for it in this order:

  • A hard-coded WOLFSSL_ROOT cmake variable.
  • WOLFSSL_ROOT Environment Variable
  • The CONFIG_CUSTOM_SETTING_WOLFSSL_ROOT value in the sdkconfig file, from the Kconfig option.
  • Any parent directories, up to the root (if this directory is in the ESP-IDF components)
  • Any parent directories, up to the root (if this directory is a project component)

While recursing up the directory tree, the following names of wolfSSL directories will be considered:

  • wolfssl-[current user name]
  • wolfssl-master
  • wolfssl

Getting Started

See the Espressif Getting Started Guide.

# Set environment variable to ESP-IDF location
# For example, VisualGDB in WSL
WRK_IDF_PATH=/mnt/c/SysGCC/esp32/esp-idf/v5.2
WRK_IDF_PATH=/mnt/c/SysGCC/esp32-master/esp-idf/v5.3-master

# Or wherever the ESP-IDF is installed:
WRK_IDF_PATH=~/esp/esp-idf

echo "Run export.sh from ${WRK_IDF_PATH}"
. ${WRK_IDF_PATH}/export.sh

cd [your project]

idf.py menuconfig

Enable wolfSSL to be used in the ESP-TLS:

Component config  --->
    ESP-TLS  --->
        Choose SSL/TLS library for ESP-TLS (See help for more Info)
            (X) wolfSSL (License info in wolfSSL directory README)

Adjust wolfSSL settings, such as path to source code as needed:

Component config  --->
    wolfSSL  --->
        [*] Include wolfSSL in ESP-TLS
        [*] Use the specified wolfssl for ESP-TLS
        (~/workspace/wolfssl) Enter a path for wolfSSL source code

Configuration

All settings for wolfSSL are adjusted in the include/user_settings.h file.

The user_settings.h file should not be included directly. Instead, #include <wolfssl/wolfcrypt/settings.h> before any other wolfSSL headers, like this:

/* ESP-IDF */
#include <esp_log.h>
#include "sdkconfig.h"

/* wolfSSL */
/* Always include wolfcrypt/settings.h before any other wolfSSL file.    */
/* Reminder: settings.h pulls in user_settings.h; don't include it here. */
#if defined(WOLFSSL_USER_SETTINGS)
    #include <wolfssl/wolfcrypt/settings.h>
    #if defined(WOLFSSL_ESPIDF)
        #include <wolfssl/version.h>
        #include <wolfssl/wolfcrypt/types.h>
        #include <wolfcrypt/test/test.h>
        #include <wolfssl/wolfcrypt/port/Espressif/esp-sdk-lib.h>
        #include <wolfssl/wolfcrypt/port/Espressif/esp32-crypt.h>
    #else
        #error "Problem with wolfSSL user_settings. "           \
               "Check components/wolfssl/include "              \
               "and confirm WOLFSSL_USER_SETTINGS is defined, " \
               "typically in the component CMakeLists.txt"
    #endif
#else
    /* Define WOLFSSL_USER_SETTINGS project wide for settings.h to include   */
    /* wolfSSL user settings in ./components/wolfssl/include/user_settings.h */
    #error "Missing WOLFSSL_USER_SETTINGS in CMakeLists or Makefile:\
    CFLAGS +=-DWOLFSSL_USER_SETTINGS"
#endif

Examples

See the wolfSSL examples:

Platforms

The ESP-IDF wolfSSL is also available for PlatformIO:

The wolfSSL library can also be used for Espressif with Arduino:

Additional Information

Contact

Have a specific request or questions? We'd love to hear from you! Please contact us at support@wolfssl.com or open an issue on GitHub.

Licensing and Support

wolfSSL (formerly known as CyaSSL) and wolfCrypt are either licensed for use under the GPLv3 (or at your option any later version) or a standard commercial license. For our users who cannot use wolfSSL under GPLv3 (or any later version), a commercial license to wolfSSL and wolfCrypt is available.

See the LICENSE.txt, visit wolfssl.com/license, contact us at licensing@wolfssl.com or call +1 425 245 8247

View Commercial Support Options: wolfssl.com/products/support-and-maintenance