Add SLH-DSA support for the TLS 1.3 and DTLS 1.3 handshake by Frauschi · Pull Request #10901 · wolfSSL/wolfssl

Frauschi · 2026-07-14T17:57:26Z

Summary

Adds SLH-DSA (SPHINCS+, FIPS 205) as an entity authentication algorithm for the TLS 1.3 and DTLS 1.3 handshake, following draft-reddy-tls-slhdsa. An SLH-DSA leaf key can now be used to sign (and a peer's SLH-DSA leaf to verify) the CertificateVerify message, for both server and mutual authentication.

All twelve parameter sets are wired into the handshake — the SHAKE and SHA2 hash families across 128/192/256 in both the f (fast) and s (small) variants — with per-parameter-set gating so a build only offers, accepts, and maps the variants actually compiled in. Test certificates and configs cover the 128f and 128s sets for both hash families.

Motivation

SLH-DSA is a stateless hash-based signature scheme standardized in FIPS 205. Its appeal is a conservative security foundation (hash functions only), but its signatures are large — from ~7.8 KB (128s) up to ~49 KB (256f) — which stresses several fixed-size buffers in the TLS/cert code that were sized for classical signatures. This PR adds the protocol support and the buffer-sizing work needed to make it viable, including on memory-constrained targets.

What's included

Handshake integration

Map the SLH-DSA signature schemes to/from the wire in the signature_algorithms extension and CertificateVerify.
Sign/verify CertificateVerify with an SLH-DSA entity key.
Load SLH-DSA private keys and certificates and resolve their key/param types (ssl_load.c, ssl.c, ssl_api_pk.c, asn.c, wc_slhdsa.h).
Advertisement, mapping, and OID handling are gated per parameter set, so partial builds (e.g. --enable-slhdsa=sha2-128s) never advertise or map a variant they cannot perform.

Streamed CertificateVerify send (large signatures)

When the CertificateVerify body exceeds a single record, the signature is generated once into a connection-level buffer and emitted one record at a time, so the output buffer never has to hold the whole signature.

Resumes correctly across a non-blocking WANT_WRITE without recomputing the randomized signature (the already-sent records are bound into the transcript, so the resumed send must emit the identical bytes — this is a correctness requirement, not an optimization).
Gated by WOLFSSL_TLS13_STREAM_CERT_VERIFY (TLS 1.3, non-async, PQC signatures). It is algorithm-neutral — it also applies to ML-DSA (or any scheme) whenever the body exceeds the negotiated max_fragment_length.
DTLS 1.3 and WOLFSSL_ASYNC_CRYPT builds keep the existing in-place fragmented path (see Scope / carve-outs).
Dual-algorithm (WOLFSSL_DUAL_ALG_CERTS, BOTH) bodies stream as well: the combined two-signature body is sized from per-signature upper bounds and the exact length is recorded after signing (trailing slack is never sent).

Peak send-side memory is ≈ one signature + one record (the record is at most 16 KB, or the negotiated max_fragment_length if smaller), versus the ~2× a naive in-place send holds (the assembled body plus a copy). The reduction is largest exactly where it matters for constrained devices — a small max_fragment_length, where the second term is sub-KB and the peak is essentially the signature itself. It also stops the output buffer from staying inflated to the whole signature for the connection's lifetime.

Buffer sizing

MAX_X509_SIZE is now parameter-aware for post-quantum certificates, sized from the largest enabled SLH-DSA/ML-DSA signature. The previous flat 8 KB could not hold an SLH-DSA-signed certificate (~8.5 KB), which silently broke the static session-certificate cache paths.
The CertificateVerify and PreTBS buffers are sized from the actual signature length instead of the worst-case WC_MAX_CERT_VERIFY_SZ (which balloons to ~50 KB with SLH-DSA). WC_MAX_CERT_VERIFY_SZ is retained for API/backward compatibility and documented as no longer used internally.

Tests and certificates

SLH-DSA entity (client/server) certificates for the SHAKE and SHA2 128f/128s parameter sets, plus generation-script updates.
TLS 1.3 and DTLS 1.3 entity-cert CertificateVerify test configs covering the fragmented (128f) and single-record (128s) send paths for both hash families, wired into suites.c (server-auth + mutual-auth scenarios).

Enabling

./configure --enable-slhdsa            # all parameter sets (SHAKE)
./configure --enable-slhdsa=sha2       # SHA2 family
./configure --enable-slhdsa=128s,128f  # specific parameter sets

TLS 1.3 is required (enabled by default). The SHA2 family additionally requires SHA-256, SHA-512, and HMAC.

Scope / carve-outs

DTLS 1.3 is intentionally not on the streaming path. DTLS fragments at the handshake layer (offset/length) via Dtls13HandshakeSend, and its reliability model must retain the full message for retransmission until ACKed — so streaming yields no memory benefit there. A code comment in Dtls13SendFragmented records the follow-up (sign directly into the fragments buffer to avoid the transient second copy; the retransmit copy is a hard floor).
WOLFSSL_ASYNC_CRYPT builds keep the existing in-place fragmented path. Async introduces a record-AEAD WC_PENDING_E resume point whose cursor-timing requirement conflicts with the non-blocking WANT_WRITE cursor; the in-place path already handles both correctly. Async targets (HW-offload servers) are not memory-constrained, so there is no beneficiary for the added complexity.

Testing

Full ./tests/unit.test suite: pass (normal handshakes + all SLH-DSA configs + DTLS + crypto API tests).
Streamed path (128f, server + mutual auth): pass.
Single-record path (128s) and DTLS 1.3 in-place path: pass.
Full library build with -Werror: clean; verified the streaming feature-macro
off path (classical/async builds) also compiles clean.

Known limitations / follow-ups

Test coverage exercises the 128f/128s fragmentation boundaries; the 192f/256f parameter sets (deepest fragmentation, up to ~49 KB) are not yet covered at the TLS layer. Adding a 192f/256f entity config (guarded on the corresponding WOLFSSL_SLHDSA_PARAM_* macros) would strengthen the streaming/fragmentation coverage.
The streamed dual-algorithm (WOLFSSL_DUAL_ALG_CERTS, BOTH) path with a fragment-sized signature is not covered by a test config (no dual-alg SLH-DSA test certificates exist); it is correct by construction but unexercised.
Dual-alg alt-signature verification now uses a tight computed PreTBS bound rather than a fixed size; a regression test for a valid dual-alg certificate with a large alternative signature would be good hygiene.
DTLS memory reduction (sign into the fragments buffer) is noted in-code as a possible future optimization.

github-actions · 2026-07-14T18:13:15Z

MemBrowse Memory Report

gcc-arm-cortex-m3

FLASH: .text -4 B (-0.0%, 122,599 B / 262,144 B, total: 47% used)

gcc-arm-cortex-m4-dtls13

FLASH: .text +320 B (+0.2%, 181,412 B / 1,048,576 B, total: 17% used)

gcc-arm-cortex-m4-openssl-compat

FLASH: .text +640 B (+0.1%, 770,300 B / 1,048,576 B, total: 73% used)

gcc-arm-cortex-m4-pq

FLASH: .text +768 B (+0.3%, 280,768 B / 1,048,576 B, total: 27% used)

gcc-arm-cortex-m4-rsa-only

FLASH: .text +320 B (+0.1%, 326,488 B / 1,048,576 B, total: 31% used)

gcc-arm-cortex-m4-tls13

FLASH: .text +320 B (+0.1%, 236,999 B / 262,144 B, total: 90% used)

gcc-arm-cortex-m7-pq

FLASH: .text +768 B (+0.3%, 281,344 B / 1,048,576 B, total: 27% used)

gcc-arm-cortex-m7-tls13

FLASH: .text +320 B (+0.1%, 237,063 B / 262,144 B, total: 90% used)

linuxkm-standard

Data: __patchable_function_entries +8 B (+0.0%, 48,664 B)
No memory changes detected for:
gcc-arm-cortex-m0plus
gcc-arm-cortex-m4
gcc-arm-cortex-m4-baremetal
gcc-arm-cortex-m4-crypto-only
gcc-arm-cortex-m4-min-ecc
gcc-arm-cortex-m4-pkcs7
gcc-arm-cortex-m4-sp-math
gcc-arm-cortex-m4-tls12
gcc-arm-cortex-m7
linuxkm-pie
stm32-sim-stm32h753

Frauschi · 2026-07-15T06:06:30Z

Jenkins retest this please

wolfSSL-Fenrir-bot

Fenrir Automated Review — PR #10901

Scan targets checked: wolfcrypt-bugs, wolfcrypt-port-bugs, wolfcrypt-rs-bugs, wolfcrypt-src, wolfssl-bugs, wolfssl-src

Findings: 1
1 finding(s) posted as inline comments (see file-level comments below)

This review was generated automatically by Fenrir. Findings are non-blocking.

wolfSSL-Fenrir-bot

Fenrir Automated Review — PR #10901

Scan targets checked: wolfcrypt-bugs, wolfcrypt-port-bugs, wolfcrypt-rs-bugs, wolfcrypt-src, wolfssl-bugs, wolfssl-src
Findings: 3
2 finding(s) posted as inline comments (see file-level comments below)

Info (1)

SHAKE-variant SLH-DSA cases in EncodeSigAlg lack per-parameter-set guards

Function: EncodeSigAlg
Category: Code Consistency / Defensive Programming

The SHA2-family SLH-DSA cases in EncodeSigAlg are individually gated (e.g. #ifdef WOLFSSL_SLHDSA_PARAM_SHA2_128S) whereas the SHAKE-family cases fall through under the single #ifdef WOLFSSL_HAVE_SLHDSA umbrella. This is an internal inconsistency: if WOLFSSL_HAVE_SLHDSA is defined but a specific SHAKE parameter set (e.g. WOLFSSL_SLHDSA_PARAM_128F) is not, the corresponding case statement is still compiled in even though it can never be reached. AddSuiteHashSigAlgo, which feeds the negotiated suite, is correctly per-variant gated, so the enum value would never appear in args->sigAlgo. Because AddSuiteHashSigAlgo, SlhDsaSigMinorToType, and ProcessBufferTryDecodeSlhDsa all enforce per-parameter-set guards at the point where an algorithm is admitted into the session, a SHAKE variant that is not compiled in cannot appear in a live handshake.

Recommendation: For consistency with the SHA2 branch and to make dead-code elimination explicit, add per-parameter-set preprocessor guards around each SHAKE case in EncodeSigAlg. No functional or security change results; the improvement is defensive consistency.

This review was generated automatically by Fenrir. Findings are non-blocking.

wolfSSL-Fenrir-bot

Fenrir Automated Review — PR #10901

Scan targets checked: wolfcrypt-bugs, wolfcrypt-port-bugs, wolfcrypt-rs-bugs, wolfcrypt-src, wolfssl-bugs, wolfssl-src

Findings: 2
2 finding(s) posted as inline comments (see file-level comments below)

This review was generated automatically by Fenrir. Findings are non-blocking.

wolfSSL-Fenrir-bot

Fenrir Automated Review — PR #10901

Scan targets checked: wolfcrypt-bugs, wolfcrypt-port-bugs, wolfcrypt-rs-bugs, wolfcrypt-src, wolfssl-bugs, wolfssl-src

Findings: 2
2 finding(s) posted as inline comments (see file-level comments below)

This review was generated automatically by Fenrir. Findings are non-blocking.

wolfSSL-Fenrir-bot

Fenrir Automated Review — PR #10901

Scan targets checked: wolfcrypt-bugs, wolfcrypt-port-bugs, wolfcrypt-rs-bugs, wolfcrypt-src, wolfssl-bugs, wolfssl-src

Findings: 2
2 finding(s) posted as inline comments (see file-level comments below)

This review was generated automatically by Fenrir. Findings are non-blocking.

wolfSSL-Fenrir-bot

Fenrir Automated Review — PR #10901

Scan targets checked: wolfcrypt-bugs, wolfcrypt-port-bugs, wolfcrypt-rs-bugs, wolfcrypt-src, wolfssl-bugs, wolfssl-src

Findings: 2
2 finding(s) posted as inline comments (see file-level comments below)

This review was generated automatically by Fenrir. Findings are non-blocking.

Frauschi · 2026-07-20T17:33:50Z

The one CI failure (Multiple compilers and versions / Compiler test) will be resolved by #10951 .

Frauschi · 2026-07-21T10:31:21Z

Jenkins retest this please

wolfSSL-Fenrir-bot

Fenrir Automated Review — PR #10901

Scan targets checked: wolfcrypt-bugs, wolfcrypt-port-bugs, wolfcrypt-rs-bugs, wolfcrypt-src, wolfssl-bugs, wolfssl-src

Findings: 1
1 finding(s) posted as inline comments (see file-level comments below)

This review was generated automatically by Fenrir. Findings are non-blocking.

wolfSSL-Fenrir-bot

Fenrir Automated Review — PR #10901

Scan targets checked: wolfcrypt-bugs, wolfcrypt-port-bugs, wolfcrypt-rs-bugs, wolfcrypt-src, wolfssl-bugs, wolfssl-src
Findings: 4
2 finding(s) posted as inline comments (see file-level comments below)

Low (1)

SLH-DSA alternative-signature not verified in WOLFSSL_CKS_SIGSPEC_BOTH mode

File: src/tls13.c:12305-12415
Function: DoTls13CertificateVerify
Category: Missing Authentication Step

When WOLFSSL_DUAL_ALG_CERTS is enabled and the negotiated CKS extension value is WOLFSSL_CKS_SIGSPEC_BOTH, the code at DoTls13CertificateVerify TLS_ASYNC_DO decodes the alternative SLH-DSA key via decodeSlhDsaKey (tls13.c:11807-11821) into ssl->peerSlhDsaKey. However, the subsequent alternative-signature verification block (tls13.c:12305-12415) handles RSA, ECC, and ML-DSA alternative signatures but contains no WOLFSSL_HAVE_SLHDSA case for verifying the alternative SLH-DSA signature. Consequently args->altPeerAuthGood is never set to 1. At TLS_ASYNC_FINALIZE (tls13.c:12466-12470), ssl->options.peerAuthGood is overwritten with args->altPeerAuthGood (0), so the handshake is rejected. The security outcome is conservative: authentication fails rather than being bypassed. However, any legitimate dual-algorithm session where SLH-DSA is the alternative key and SIGSPEC_BOTH is negotiated will always be rejected by a wolfSSL endpoint compiled with WOLFSSL_DUAL_ALG_CERTS, rendering that configuration non-functional. The primary (native) signature IS correctly verified and is what prevents any authentication bypass; the missing alt-sig verify step merely means the required second check never passes.

Recommendation: Add a WOLFSSL_HAVE_SLHDSA case inside the WOLFSSL_DUAL_ALG_CERTS alternative-signature verification block in DoTls13CertificateVerify (around tls13.c:12409, after the ML-DSA block). The case should:

Call wc_SlhDsaKey_Verify with sig advanced past the primary signature (as done at line 12309)
Pass args->altSignatureSz, args->altSigData/altSigDataSz
Set args->altPeerAuthGood=1 on success
Free peerSlhDsaKey appropriately
Add a parameter-set consistency check analogous to tls13.c:12273-12276

Alternatively, if SLH-DSA as an alternative key is intentionally unsupported, the decode switch at tls13.c:11807-11821 should return ALGO_ID_E for all SLH-DSA cases to fail fast rather than allocating a key that is never verified.

Referenced code: src/tls13.c:12305-12317 (13 lines)

Info (1)

decodeSlhDsaKey sets peerSlhDsaKeyPresent before wc_SlhDsaKey_Init succeeds

Function: decodeSlhDsaKey
Category: Key Lifecycle / Resource Management

In decodeSlhDsaKey, ssl->peerSlhDsaKeyPresent is set to 1 (line 11572) before the re-initialization sequence: wc_SlhDsaKey_Free (line 11576) then wc_SlhDsaKey_Init (line 11577). If wc_SlhDsaKey_Init fails, the function returns PEER_KEY_ERROR with peerSlhDsaKeyPresent=1 but the key's params field is NULL (set by wc_SlhDsaKey_Free at wc_slhdsa.c:6880). Subsequent cleanup paths (exit_dcv → wolfSSL_ResourceFree → FreeKey → wc_SlhDsaKey_Free → XFREE) are safe: wc_SlhDsaKey_Free guards all hash-object frees with if (key->params != NULL), making it a no-op on the NULL-params key before XFREE frees the struct. No double-free, no use-after-free, no memory leak results. Noted here because the ordering (flag set before Init completes) could confuse future maintenance.

Recommendation: Move ssl->peerSlhDsaKeyPresent = 1 to after the successful wc_SlhDsaKey_Init call (i.e., after the if (keyRet != 0) return PEER_KEY_ERROR check at line 11580). This makes the invariant explicit: the Present flag is true only when the key is fully initialized. This pattern is already used correctly in the analogous decodeMlDsaKey and decodeFalconKey functions.

This review was generated automatically by Fenrir. Findings are non-blocking.

wolfSSL-Fenrir-bot

Fenrir Automated Review — PR #10901

Scan targets checked: wolfcrypt-bugs, wolfcrypt-port-bugs, wolfcrypt-rs-bugs, wolfcrypt-src, wolfssl-bugs, wolfssl-src

Findings: 2
2 finding(s) posted as inline comments (see file-level comments below)

This review was generated automatically by Fenrir. Findings are non-blocking.

Implement SLH-DSA (SPHINCS+, FIPS 205) as an entity authentication algorithm for the TLS 1.3 and DTLS 1.3 handshake, following draft-reddy-tls-slhdsa. All twelve parameter sets (SHAKE and SHA2 families, 128/192/256 in the f and s variants) are wired into the handshake for signing and verifying the CertificateVerify message; test certificates and configs cover the 128f and 128s sets. Handshake integration: - Map the SLH-DSA signature schemes to and from the wire in the signature_algorithms extension and CertificateVerify. The mapping, advertisement, and OID handling are gated per parameter set so a build only offers, accepts, and maps the variants actually compiled in (including partial SHA2 builds). - Sign and verify the CertificateVerify with an SLH-DSA entity key, and load SLH-DSA private keys and certificates (ssl_load.c, ssl.c, ssl_api_pk.c, asn.c). Streamed CertificateVerify send: - SLH-DSA signatures are large (up to ~50 KB). When the CertificateVerify body exceeds a single record, generate the signature into a connection-level buffer and emit it one record at a time so the output buffer never has to hold the whole signature. This keeps peak memory near one signature plus a single fragment and resumes correctly across a non-blocking WANT_WRITE without recomputing the randomized signature. Gated by WOLFSSL_TLS13_STREAM_CERT_VERIFY (TLS 1.3, non-async, PQC signatures); DTLS and WOLFSSL_ASYNC_CRYPT keep the existing in-place fragmented path. - Dual-algorithm (WOLFSSL_DUAL_ALG_CERTS, BOTH) CertificateVerify bodies are streamed as well. The combined two-signature body may include a variable-length signature, so the body buffer is sized from the per-signature upper bounds and the exact length is recorded after signing; the small trailing slack is never sent. Buffer sizing: - Make MAX_X509_SIZE parameter-aware for post-quantum certificates, sizing it from the largest enabled SLH-DSA or ML-DSA signature rather than a flat 8 KB that cannot hold an SLH-DSA-signed certificate. - Size the CertificateVerify and PreTBS buffers from the actual signature length instead of the worst-case WC_MAX_CERT_VERIFY_SZ, which balloons with SLH-DSA. WC_MAX_CERT_VERIFY_SZ is retained for API compatibility. Tests and certificates: - Add SLH-DSA entity (client and server) certificates for the SHAKE and SHA2 128f and 128s parameter sets, and update the generation script. - Add TLS 1.3 and DTLS 1.3 entity-cert CertificateVerify test configs covering the fragmented (128f) and single-record (128s) send paths for both hash families, wired into suites.c. Build configuration: - configure.ac: --enable-slhdsa now keeps the certificate/ASN code enabled (as --enable-mldsa does), so an SLH-DSA-only build with RSA, ECC and DH disabled configures instead of erroring that ASN is off. - Guard the WOLFSSL, WOLFSSL_CTX and WOLFSSL_X509 pkCurveOID members for WOLFSSL_HAVE_SLHDSA, so an SLH-DSA-only build declares the field the handshake and CopyDecodedToX509 already reference under an SLH-DSA guard. - Mark checkKeySz used in the SLH-DSA branch of ProcessBufferCertPublicKey; SLH-DSA is the only certificate signature algorithm with no minimum-size check, so an SLH-DSA-only build otherwise tripped -Wunused-parameter. - SLH-DSA CertificateVerify: preserve the verify return code on failure rather than flattening every non-zero result to SIG_VERIFY_E. wc_SlhDsaKey_Verify already returns SIG_VERIFY_E on a real mismatch, so the failure semantics are unchanged while WC_PENDING_E (async crypto callbacks) and hard errors now propagate, matching the ML-DSA/Falcon verify blocks. - CI: add a SHA2-only SLH-DSA build (--enable-slhdsa=sha2) to pq-all.yml so the SHAKE-disabled combined-maxima guards are exercised - a SHAKE-off build must still size the FORS/XMSS buffers for the 192/256-bit SHA2 parameters. - Tests: add an API-level memio test (test_slhdsa_tls13_certverify_want_write) that forces a WANT_WRITE partway through a fragmented SLH-DSA-SHAKE-128f CertificateVerify and asserts the handshake still completes, covering the streamed-CertificateVerify resume branch (fragOffset != 0 re-entry) that the blocking .conf handshakes never exercise.

Frauschi · 2026-07-24T15:05:21Z

Jenkins retest this please

Frauschi self-assigned this Jul 14, 2026

Frauschi force-pushed the slhdsa_tls_handshake branch 3 times, most recently from cf4f9cd to 417c06f Compare July 14, 2026 19:46

Frauschi requested a review from wolfSSL-Fenrir-bot July 15, 2026 06:07

wolfSSL-Fenrir-bot reviewed Jul 15, 2026

View reviewed changes

Comment thread src/tls13.c

Frauschi force-pushed the slhdsa_tls_handshake branch from 417c06f to e7100ab Compare July 15, 2026 09:21

Frauschi commented Jul 15, 2026

View reviewed changes

Comment thread src/tls13.c

Frauschi assigned wolfSSL-Bot and unassigned Frauschi Jul 15, 2026

Frauschi requested a review from wolfSSL-Fenrir-bot July 15, 2026 11:45

wolfSSL-Fenrir-bot reviewed Jul 15, 2026

View reviewed changes

Comment thread wolfcrypt/src/asn.c Outdated

Comment thread src/tls13.c

Frauschi force-pushed the slhdsa_tls_handshake branch from e7100ab to ac897d5 Compare July 15, 2026 15:39

Frauschi commented Jul 15, 2026

View reviewed changes

Comment thread wolfcrypt/src/asn.c Outdated

Frauschi commented Jul 15, 2026

View reviewed changes

Comment thread src/tls13.c

Frauschi requested a review from wolfSSL-Fenrir-bot July 15, 2026 15:44

wolfSSL-Fenrir-bot reviewed Jul 15, 2026

View reviewed changes

Comment thread src/tls13.c Outdated

Comment thread tests/suites.c

Frauschi commented Jul 16, 2026

View reviewed changes

Comment thread tests/suites.c

Frauschi force-pushed the slhdsa_tls_handshake branch from ac897d5 to f759960 Compare July 16, 2026 06:43

Frauschi commented Jul 16, 2026

View reviewed changes

Comment thread src/tls13.c Outdated

Frauschi requested a review from wolfSSL-Fenrir-bot July 16, 2026 09:06

wolfSSL-Fenrir-bot reviewed Jul 16, 2026

View reviewed changes

Comment thread src/tls13.c

Comment thread src/internal.c

Frauschi force-pushed the slhdsa_tls_handshake branch from f759960 to 9e96534 Compare July 16, 2026 10:14

Frauschi commented Jul 16, 2026

View reviewed changes

Comment thread src/internal.c

Frauschi commented Jul 16, 2026

View reviewed changes

Comment thread src/tls13.c

Frauschi requested a review from wolfSSL-Fenrir-bot July 16, 2026 10:31

wolfSSL-Fenrir-bot reviewed Jul 16, 2026

View reviewed changes

Comment thread src/tls13.c Outdated

Comment thread src/dtls13.c

Frauschi commented Jul 16, 2026

View reviewed changes

Comment thread src/tls13.c Outdated

Frauschi force-pushed the slhdsa_tls_handshake branch 2 times, most recently from ac897d5 to 8bdb3d0 Compare July 20, 2026 12:37

Frauschi requested a review from wolfSSL-Fenrir-bot July 20, 2026 12:40

Frauschi force-pushed the slhdsa_tls_handshake branch from 8bdb3d0 to 728d60e Compare July 20, 2026 13:27

wolfSSL-Fenrir-bot reviewed Jul 20, 2026

View reviewed changes

Comment thread src/tls13.c

Comment thread src/tls13.c Outdated

Frauschi force-pushed the slhdsa_tls_handshake branch 2 times, most recently from a2e3d4f to 6d1867a Compare July 20, 2026 13:51

Frauschi commented Jul 20, 2026

View reviewed changes

Comment thread src/tls13.c

Frauschi commented Jul 20, 2026

View reviewed changes

Comment thread src/tls13.c Outdated

Frauschi force-pushed the slhdsa_tls_handshake branch 2 times, most recently from fd59398 to 0977af6 Compare July 21, 2026 07:51

Frauschi force-pushed the slhdsa_tls_handshake branch from 0977af6 to 848d32f Compare July 23, 2026 08:52

SparkiDev requested a review from wolfSSL-Fenrir-bot July 24, 2026 00:16

wolfSSL-Fenrir-bot reviewed Jul 24, 2026

View reviewed changes

Comment thread src/ssl_load.c

SparkiDev assigned Frauschi Jul 24, 2026

Frauschi commented Jul 24, 2026

View reviewed changes

Comment thread src/ssl_load.c

Frauschi force-pushed the slhdsa_tls_handshake branch from 848d32f to f4fe428 Compare July 24, 2026 06:31

Frauschi requested a review from wolfSSL-Fenrir-bot July 24, 2026 06:32

wolfSSL-Fenrir-bot reviewed Jul 24, 2026

View reviewed changes

Comment thread src/tls13.c Outdated

Frauschi force-pushed the slhdsa_tls_handshake branch from f4fe428 to 3e7da8e Compare July 24, 2026 08:45

Frauschi commented Jul 24, 2026

View reviewed changes

Comment thread src/tls13.c Outdated

Frauschi requested a review from wolfSSL-Fenrir-bot July 24, 2026 08:54

wolfSSL-Fenrir-bot reviewed Jul 24, 2026

View reviewed changes

Comment thread src/tls13.c Outdated

Comment thread src/tls13.c

Frauschi force-pushed the slhdsa_tls_handshake branch from 3e7da8e to 913ea97 Compare July 24, 2026 10:27

Frauschi force-pushed the slhdsa_tls_handshake branch from 913ea97 to 7ed7f80 Compare July 24, 2026 13:47

Frauschi removed their assignment Jul 24, 2026

Uh oh!

Conversation

Frauschi commented Jul 14, 2026

Summary

Motivation

What's included

Handshake integration

Streamed CertificateVerify send (large signatures)

Buffer sizing

Tests and certificates

Enabling

Scope / carve-outs

Testing

Known limitations / follow-ups

Uh oh!

github-actions Bot commented Jul 14, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

MemBrowse Memory Report

Uh oh!

Frauschi commented Jul 15, 2026

Uh oh!

wolfSSL-Fenrir-bot left a comment

Choose a reason for hiding this comment

Fenrir Automated Review — PR #10901

Uh oh!

Uh oh!

Uh oh!

wolfSSL-Fenrir-bot left a comment

Choose a reason for hiding this comment

Fenrir Automated Review — PR #10901

Info (1)

SHAKE-variant SLH-DSA cases in EncodeSigAlg lack per-parameter-set guards

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

wolfSSL-Fenrir-bot left a comment

Choose a reason for hiding this comment

Fenrir Automated Review — PR #10901

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

wolfSSL-Fenrir-bot left a comment

Choose a reason for hiding this comment

Fenrir Automated Review — PR #10901

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

wolfSSL-Fenrir-bot left a comment

Choose a reason for hiding this comment

Fenrir Automated Review — PR #10901

Uh oh!

Uh oh!

Uh oh!

Uh oh!

wolfSSL-Fenrir-bot left a comment

Choose a reason for hiding this comment

Fenrir Automated Review — PR #10901

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Frauschi commented Jul 20, 2026

Uh oh!

Frauschi commented Jul 21, 2026

Uh oh!

wolfSSL-Fenrir-bot left a comment

Choose a reason for hiding this comment

Fenrir Automated Review — PR #10901

Uh oh!

Uh oh!

Uh oh!

wolfSSL-Fenrir-bot left a comment

Choose a reason for hiding this comment

github-actions Bot commented Jul 14, 2026 •

edited

Loading