mirror of
https://github.com/wolfSSL/wolfssl.git
synced 2026-08-13 23:21:25 +02:00
Tobias Frauenschläger
f5f3dd4c6e
Allow a quantum-safe-only TLS 1.3 stack - ML-KEM key exchange with ML-DSA or SLH-DSA authentication - with RSA, ECC and DH all disabled (the CNSA 2.0 / EO 14412 posture). - Treat a usable standalone ML-KEM group as a valid key exchange and Falcon/ML-DSA/SLH-DSA as valid authentication, so the "no cipher suites" #errors no longer fire (ssl.c, internal.h), and extend the CopyDecodedToX509 pkCurveOID guard to match the struct member guards (internal.c). - asn.c: guard the RSA/ECC-only certificate signing helpers so cert generation compiles with RSA and ECC disabled, while keeping MakeSignatureCb available for the WOLFSSL_CERT_SIGN_CB (TPM/HSM) offload path. - tls.c: advertise the psk_dhe_ke exchange mode when a standalone ML-KEM group is usable on the client side, that is when the build has both key generation and decapsulation. Without it an ML-KEM-only build fell back to psk_ke, the resumption key schedules diverged, and the first AEAD record failed to authenticate (AES_GCM_AUTH_E), breaking session-ticket resumption. - tls13.c: hoist the hashAlgo void cast in EncodeSigAlg out of the Ed25519 and Ed448 cases so a build with no classic signature algorithm still marks the parameter used. - Examples and tests: add ML-DSA and SLH-DSA certificate selection (gated on NO_RSA so it only applies in true PQC-only builds) and default to TLS 1.3 when no classic auth is built in and a post-quantum signature is available (test.h, client/server/echo*, test_tls13.c). SLH-DSA uses the SHAKE-128s leaf certificates and their shared 128s root. - CI: add PQC-only entries to the pq-all.json config list (ML-DSA and SLH-DSA), each exercising the build, a full TLS 1.3 handshake, and ML-KEM-only session-ticket resumption. Whether a build can authenticate with a post-quantum certificate is three separate questions - is the algorithm compiled in, are test credentials wired up for the enabled parameter set, and can this build sign - so test.h answers them with three tiers of macro rather than testing WOLFSSL_HAVE_MLDSA and WOLFSSL_HAVE_SLHDSA directly: - TEST_HAVE_MLDSA_CERT_FILES / TEST_HAVE_SLHDSA_CERT_FILES: the credential paths name real files. ML-DSA needs an enabled parameter level; SLH-DSA needs a 128s parameter set, since both families share a 128s root and only those certificates are wired up, and PEM decoding, since the entity certificates ship as PEM only. Loading a certificate needs verification support alone, so test_tls13.c uses this tier - it only needs a certificate on the context. - TEST_HAVE_MLDSA_CERTS / TEST_HAVE_SLHDSA_CERTS: the above, plus the ability to sign. A verify-only build derives WOLFSSL_MLDSA_NO_SIGN and drops private key support entirely, so it can neither load the key nor produce a CertificateVerify. The example credential ladders use this tier. - TEST_HAVE_PQC_CERT_AUTH: either of those, plus WOLFSSL_TLS13. Both algorithms are TLS 1.3 only, so folding the version into the macro keeps the version defaults and the PSK fallbacks in the client, server and echo examples from disagreeing. Falcon is deliberately absent, having no credentials in the ladders, so a Falcon-only build keeps the historic TLS 1.2 PSK behavior. A build that fails a gate now falls back to PSK instead of naming credentials it cannot use, which removes two hard #errors that were reachable from configure: --enable-slhdsa with only non-128s parameter sets broke every build that includes test.h, even ones with RSA and ECC enabled that would never touch an SLH-DSA credential. Also in the credential material and the configurations this opens up: - test.h: pair the DER ML-DSA certificate with mldsa<N>-key.der. The mldsa<N>_priv-only.der files are standalone PKCS#8 encoding vectors from an unrelated key pair, so a build without PEM decoding presented a certificate and signed with a key that did not match it, and the peer rejected the CertificateVerify. - echoserver.c: load the SLH-DSA key with CERT_FILETYPE like every neighboring branch, rather than hardcoding WOLFSSL_FILETYPE_PEM against a certificate loaded in the build-dependent format. - internal.c, tls13.c, ssl_load.c: mark ssl, sigOut, keyType and keySz used. Every reader of these sits in a per-algorithm block, so a build with no signing algorithm at all left them unused and -Werror rejected the library. - tests/api.c: skip test_wolfSSL_PKCS8 unless RSA, ECC or PEM decoding is available. With none of them every key-loading body compiles out, leaving the file locals unused and nothing for the test to do.