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.
wolfSSL TLS Client Example
This is the wolfSSL TLS Client demo, typically used with the Espressif TLS Server or the CLI Server.
When using the CLI, see the example parameters.
For general information on wolfSSL examples for Espressif, see the README file.
Quick Start
Use the ESP-IDF for ESP32 or RTOS SDK for the ESP8266.
Run menuconfig utility (idf.py menuconfig for ESP32 or make menuconfig for the ESP8266)
and set the various parameters for the target device, along with local WiFi settings:
- Target Host:
CONFIG_WOLFSSL_TARGET_HOST(The IP address of a listening server) - Target Port:
CONFIG_WOLFSSL_TARGET_PORT(Typically11111) - Example WiFi SSID:
CONFIG_EXAMPLE_WIFI_SSID(The WiFi that you want to connect to) - Example WiFi Password:
CONFIG_EXAMPLE_WIFI_PASSWORD(The WiFi password)
The latest examples use makefiles that do not require local file copy installation of wolfSSL.
Build and flash the software to see the example in action.
Quick Start with VisualGDB
There are optional VisualGDB project files in the
VisualGDB project subdirectory, and an ESP8266 project file in the project directory,
called wolfssl_client_ESP8266.vgdbproj.
Open the VisualGDB Visual Studio Project file in the VisualGDB directory and click the "Start" button.
No wolfSSL setup is needed. You may need to adjust your specific COM port. The default is COM19.
Troubleshooting
Weird results, odd messages, unexpected compiler errors? Manually delete the build directory and
any locally generated files (sdkconfig, sdkconfig-debug, etc.) and start over.
The build directory is typically located in the root of the project directory: [project]/build.
Difficulty flashing:
- Ensure the target device has a robust, stable, clean power supply.
- Check that quality USB cables are being used.
- Try lowering the flash baud rate in the
menuconfig. The 115200 is typically reliable. - Review board specifications: some require manual boot mode via on-board buttons.
- See Espressif ESP Frequently Asked Questions
esp-faq-en-master.pdf.
ESP-IDF Commandline v5.x
-
idf.py menuconfigto config the project1-1. Example Configuration ->
Target host ip address : the host that you want to connect to.(default is 127.0.0.1)1-2. Example Connection Configuration ->
WIFI SSID: your own WIFI, which is connected to the Internet.(default is "myssid") WIFI Password: WIFI password, and default is "mypassword"Note: the example program uses 11111 port. If you want to use different port , you need to modify DEFAULT_PORT definition in the code.
When you want to test the wolfSSL client
-
idf.py -p <PORT> flashand thenidf.py monitorto load the firmware and see the context -
You can use /examples/server/server program for test.
e.g. Launch ./examples/server/server -v 4 -b -i -d
VisualGDB for ESP8266
Reminder that we build with make and not cmake in VisualGDB.
Build files will be created in [project directory]\build
See notes below if building a project in a directory other than the examples.
Problems?
- Try deleting any existing
sdkconfigfile and/or./builddirectory to start fresh. - Be sure the RTOS SDK is installed and properly configured.
ESP-IDF make Commandline (version 3.5 or earlier for the ESP8266)
In-place example build:
export IDF_PATH=~/esp/ESP8266_RTOS_SDK
export PATH="$PATH:$HOME/esp/xtensa-lx106-elf/bin"
cd /mnt/c/workspace/wolfssl-master/IDE/Espressif/ESP-IDF/examples/wolfssl_client
make clean
make
When building a in a different directory, for example assuming the wolfssl_client in the wolfssl examples
directory is copied to the C:\test\demo directory in Windows. (aka /mnt/c/test/demo in WSL),
with a clone of wolfSSL master branch in C:\workspace\wolfssl-master:
cp -r /mnt/c/workspace/wolfssl-master/IDE/Espressif/ESP-IDF/examples/wolfssl_client/* /mnt/c/test/demo
Modify the project ./components/wolfssl/component.mk file. Adjust WOLFSSL_ROOT setting, in this case to a value of:
WOLFSSL_ROOT := ../../../../workspace/wolfssl-master
Ensure the path is relative to the project component.mk file location and not absolute.
Note the location of the component makefile in this case is c:\test\demo\components\wolfssl\component.mk.
Thus we need to navigate up 4 parents to the root of C:\ to find /mnt/c in WSL.
Proceed to run make from the project directory as usual:
# setup environment as needed
export IDF_PATH=~/esp/ESP8266_RTOS_SDK
export PATH="$PATH:$HOME/esp/xtensa-lx106-elf/bin"
# copy and navigate to project directory
mkdir -p /mnt/c/test/demo
cp -r /mnt/c/workspace/wolfssl-master/IDE/Espressif/ESP-IDF/examples/wolfssl_client/* /mnt/c/test/demo
cd /mnt/c/test/demo
# Clean
rm -rf ./build
rm sdkconfig
make clean
# Edit ./components/wolfssl/component.mk and set WOLFSSL_ROOT value
# WOLFSSL_ROOT := ../../../../workspace/wolfssl-master
# build the example project
make
When using make there should be details in the build log to indicate
the assigned path, and the equivalent, fully-qualified path of WOLFSSL_ROOT.
************* wolfssl_client *************
*********** wolfssl component ************
WOLFSSL_ROOT defined: ../../../../workspace/wolfssl-master
WOLFSSL_ROOT actual: /mnt/c/workspace/wolfssl-master
********** end wolfssl component **********
ESP-IDF CMake Commandline (version 3.5 or earlier for the ESP8266)
Build files will be created in [project directory]\build\debug
# Set your path to RTOS SDK, shown here for default from WSL with VisualGDB
WRK_IDF_PATH=/mnt/c/SysGCC/esp8266/rtos-sdk/v3.4
# or
WRK_IDF_PATH=~/esp/ESP8266_RTOS_SDK
# Setup the environment
. $WRK_IDF_PATH/export.sh
# install as needed / prompted
/mnt/c/SysGCC/esp8266/rtos-sdk/v3.4/install.sh
# Fetch wolfssl from GitHub if needed:
cd /workspace
git clone https://github.com/wolfSSL/wolfssl.git
# change directory to wolfssl client example.
cd wolfssl/IDE/Espressif/ESP-IDF/examples/wolfssl_client
# or for example, WSL with C:\workspace as home for git clones:
# cd /mnt/c/workspace/wolfssl-$USER/IDE/Espressif/ESP-IDF/examples/wolfssl_client
# adjust settings as desired
idf.py menuconfig
idf.py build flash -p /dev/ttyS70 -b 115200
idf.py monitor -p /dev/ttyS70 -b 74880
SM Ciphers
(TODO coming soon) See https://github.com/wolfSSL/wolfsm
Working Linux Client to ESP32 Server Example:
./examples/client/client -h 192.168.1.37 -p 11111 -v 3
-c <file> Certificate file, default ./certs/client-cert.pem
-k <file> Key file, default ./certs/client-key.pem
-A <file> Certificate Authority file, default ./certs/ca-cert.pem
Example client, with default certs explicitly given:
./examples/client/client -h 192.168.1.37 -p 11111 -v 3 -c ./certs/client-cert.pem -k ./certs/client-key.pem -A ./certs/ca-cert.pem
Example client, with RSA 1024 certs explicitly given:
./examples/client/client -h 192.168.1.37 -p 11111 -v 3 -c ./certs/1024/client-cert.pem -k ./certs/1024/client-key.pem -A ./certs/1024/ca-cert.pem
Command:
cd /mnt/c/workspace/wolfssl-$USER/IDE/Espressif/ESP-IDF/examples/wolfssl_server
. /mnt/c/SysGCC/esp32/esp-idf/v5.2/export.sh
idf.py flash -p /dev/ttyS19 -b 115200 monitor
cd /mnt/c/workspace/wolfssl-$USER
./examples/client/client -h 192.168.1.108 -v 4 -l TLS_SM4_GCM_SM3 -c ./certs/sm2/client-sm2.pem -k ./certs/sm2/client-sm2-priv.pem -A ./certs/sm2/root-sm2.pem -C
Output:
SSL version is TLSv1.3
SSL cipher suite is TLS_SM4_GCM_SM3
SSL curve name is SM2P256V1
I hear you fa shizzle!
Linux client to Linux server:
./examples/client/client -h 127.0.0.1 -v 4 -l ECDHE-ECDSA-SM4-CBC-SM3 -c ./certs/sm2/client-sm2.pem -k ./certs/sm2/client-sm2-priv.pem -A ./certs/sm2/root-sm2.pem -C
./examples/server/server -v 3 -l ECDHE-ECDSA-SM4-CBC-SM3 -c ./certs/sm2/server-sm2.pem -k ./certs/sm2/server-sm2-priv.pem -A ./certs/sm2/client-sm2.pem -V
Linux Client using Kyber to ESP32 Server
# Ensure build with Kyber enabled:
# ./configure --enable-kyber=all --enable-experimental && make
./examples/client/client -h 192.168.1.38 -v 4 -l TLS_AES_128_GCM_SHA256 --pqc KYBER_LEVEL5
ESP32 Client to WSL Linux Server
In Windows Powershell, (elevated permissions) forward the port after starting the listening server:
netsh interface portproxy add v4tov4 listenport=11111 listenaddress=0.0.0.0 connectport=11111 connectaddress=127.0.0.1
After the server exits, remove the port proxy forward:
netsh interface portproxy delete v4tov4 listenport=11111 listenaddress=0.0.0.0
For additional information, see Accessing network applications with WSL.
Additional Information
See the README.md file in the upper level 'examples' directory for more information about examples.