Files
wolfssl/IDE/Espressif
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
..
2025-02-03 16:13:05 -08:00
2024-10-15 18:36:28 -07:00

wolfSSL Espressif IDE

This directory contains documentation and examples for the Espressif SoC devices.

Although wolfSSL should work on any Espressif device, there's explicit support for these:

  • esp32
  • esp32c2
  • esp32c3
  • esp32c6
  • esp32s2
  • esp32s3
  • esp32h2

Getting Started

If you are new to wolfSSL on the Espressif ESP32, this video can help to get started:

Video Preview

Additional ESP-IDF specifics can be found in Espressif/ESP-IDF. The wolfSSL Manual is also a useful resource.

Requirements

The wolfSSL Espressif code requires the ESP-IDF to be installed for Windows or Linux / MacOS.

See the Espressif Getting Started Guide.

Any editor can be used. The wolfSSL examples all include a ./VisualGDB directory with SoC-specific configurations to help get started quickly.

Although not required, a JTAG Adapter can be helpful for development. When not using a built-in JTAG from Espressif, the examples typically use the open source Tigard board.

Examples:

There are a variety of examples to help get started:

Managed Component

The wolfSSL library can be installed as a managed component:

Notes:

WSL environment:

Contents of /etc/wsl.conf:

[automount]
options = "metadata"

To ignore changes in file attributes, see https://github.com/microsoft/WSL/issues/936#issuecomment-1751469229

git config core.filemode false

Quick start


WORKSPACE=/mnt/c/workspace
WRK_IDF_PATH=/mnt/c/SysGCC/esp32/esp-idf/v5.1
WRK_WOLFSSL_PATH=${WORKSPACE}/wolfssl-$USER
WRK_PROJECT_DIR=${WRK_WOLFSSL_PATH}/IDE/Espressif/ESP-IDF/examples/wolfssl_test

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

echo "Build and flash project in ${WRK_PROJECT_DIR}"
cd ${WRK_PROJECT_DIR}
idf.py build flash -p /dev/ttyS9 -b 115200 monitor

Bad chip version:

ESP-ROM:esp32c3-20200918
Build:Sep 18 2020
rst:0x3 (RTC_SW_SYS_RST),boot:0xc (SPI_FAST_FLASH_BOOT)
Saved PC:0x403d151e
SPIWP:0xee
mode:DIO, clock div:2
load:0x3fcd6100,len:0x16c8
load:0x403ce000,len:0x930
load:0x403d0000,len:0x2d28
entry 0x403ce000
I (34) boot: ESP-IDF v4.4.2-1-g0aba20e63d-dirty 2nd stage bootloader
I (35) boot: compile time 08:29:06
I (35) boot: chip revision: 2
E (38) boot_comm: This chip is revision 2 but the application is configured for minimum revision 3. Can't run.

If you've encountered a chip version earlier than that confirmed to be working at wolfSSL, try adjusting the settings in menuconfig.

A fatal error occurred: This chip is esp[X] not esp[Y]

A fatal error occurred: This chip is ESP32-S3 not ESP32-C3. Wrong --chip argument?
CMake Error at run_serial_tool.cmake:56 (message):
  /home/gojimmypi/.espressif/python_env/idf4.4_py3.8_env/bin/python
  /mnt/c/SysGCC/esp32/esp-idf/v4.4.2/components/esptool_py/esptool/esptool.py
  --chip esp32c3 failed

Delete the ./build and rename/delete your sdkconfig file, then run idf.py set-target, in this example setting to esp32c3:

idf.py set-target esp32c3

Cmake Cache Warning

Executing action: clean
Project sdkconfig was generated for target 'esp32s3', but CMakeCache.txt contains 'esp32c3'. To keep the setting in sdkconfig (esp32s3) and re-generate CMakeCache.txt, run 'idf.py fullclean'. To re-generate sdkconfig for 'esp32c3' target, run 'idf.py set-target esp32c3'.

As indicated, run idf.py set-target and/or delete the ./build directory.

Connecting, but fails to connect.

Some devices, particularly 3rd party, non-Espressif dev boards may not have implemented the reset-program hardware properly, causing devices to not be programmed with the idf.py flash command:

Connecting......................................

A fatal error occurred: Failed to connect to ESP32: Wrong boot mode detected (0x13)! The chip needs to be in download mode.
CMake Error at run_serial_tool.cmake:56 (message):
  /home/gojimmypi/.espressif/python_env/idf4.4_py3.8_env/bin/python
  /mnt/c/SysGCC/esp32/esp-idf/v4.4.2/components/esptool_py/esptool/esptool.py
  --chip esp32 failed

Solution:

Press and hold EN button, press and release IO0 button, then release EN button.

Unknown CMake command "esptool_py_flash_project_args".

This unintuitive error was observed when including an unneeded set(COMPONENTS in the project-level CMakeLists.txt and attempting to build with an older toolchain, such as the RTOS SDK 3.4 for the ESP8266.

PermissionError: [Errno 13] Permission denied could not open port

This error, other than the obvious permissions, also occurs when the port is in use by another application:

Traceback (most recent call last):
  File "/home/gojimmypi/.espressif/python_env/rtos3.4_py3.10_env/lib/python3.10/site-packages/serial/serialposix.py", line 322, in open
    self.fd = os.open(self.portstr, os.O_RDWR | os.O_NOCTTY | os.O_NONBLOCK)
PermissionError: [Errno 13] Permission denied: '/dev/ttyS55'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
    [... snip ...]
raise SerialException(msg.errno, "could not open port {}: {}".format(self._port, msg))
serial.serialutil.SerialException: [Errno 13] could not open port /dev/ttyS55: [Errno 13] Permission denied: '/dev/ttyS55'

Panic Task watchdog got triggered.

Long-running code may trip the watchdog timer.

Task watchdog got triggered.

Guru Meditation Error: Core  0 panic'ed (unknown). Exception was unhandled.

The watchdog needs to be fed on a regular basis with void esp_task_wdt_reset(void) from esp8266/include/esp_task_wdt.h.

Try turning off the WDT in menuconfig, or for Makefiles:

EXTRA_CFLAGS += -DNO_WATCHDOG

Other Solutions

See also Espressif esp-faq-en-master.pdf