Tobias Frauenschläger
9393d62591
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 and wolfCrypt Xcode Projects for OS X and iOS
This directory contains the following files:
wolfssl.xcworkspace-- workspace with library and testsuite clientwolfssl_testsuite.xcodeproj-- project to run the testsuite.wolfssl.xcodeproj-- project to build OS/x and iOS libraries for wolfSSL and/or wolfCryptwolfssl-FIPS.xcodeproj-- project to build wolfSSL and wolfCrypt-FIPS if availableuser_settings.h-- custom library settings, which are shared across projects
The library will output as libwolfssl_osx.a or 'libwolfssl_ios.adepending on the target. It will also copy the wolfSSL/wolfCrypt (and the CyaSSL/CtaoCrypt compatibility) headers into anincludedirectory located inBuild/Products/DebugorBuild/Products/Release`.
For the library and testsuite to link properly the build location needs to be configured as realitive to workspace.
- File -> Workspace Settings (or Xcode -> Preferences -> Locations -> Locations)
- Derived Data -> Advanced
- Custom -> Relative to Workspace
- Products -> Build/Products
These Xcode projects define the WOLFSSL_USER_SETTINGS preprocessor
to enable the user_settings.h file for setting macros across
multiple projects.
If needed the Xcode preprocessors can be modified with these steps:
- Click on the Project in "Project Navigator".
- Click on the "Build Settings" tab.
- Scroll down to the "Apple LLVM 6.0 - Preprocessing" section.
- Open the disclosure for "Preprocessor Macros" and use the "+" and "-" buttons to modify. Remember to do this for both Debug and Release.
wolfSSL
This project should build wolfSSL and wolfCrypt using the default settings.
wolfSSL-FIPS
To use the FIPS version, one must have the FIPS sources. The project won't build without them. Please contact info@wolfssl.com for more information about wolfCrypt with FIPS.
By default, this builds the wolfSSL and wolfCrypt with FIPS library. The default configuration enables the settings required for FIPS. Others may be turned on. The project also ensures the FIPS related objects are linked in the proper order.
Building libwolfssl.a
There are several options of builds. You can make a simulator build, or a device build. Both are debug builds.
You can make an archive for a device, as well. That is a release build.
Known issues:
When building for older i386 architectures and using tfm.c there are specific CFLAGS required to expose the necessary registers for inline assembly in tfm.c. An example script has been provided "build-for-i386.sh" that targets the watchos by default. If using SDK iphonesimulator10.1 or older you can change the SDK variable in that script however newer versions of the SDK no longer support i386 for the iphones.
Installing libwolfssl.a
Simply drag the file libwolfssl_XXX_.a and the directory include and drop it into
your project file list pane where it makes sense for you. Allow it to copy the
files over to the project directory. This should automatically add the library
to the list of libraries to link against.
Click on your project target, then the "Build Phases" tab. On the targets list click your target. Click the disclosure triangle on the section "Link Binary With Libraries" and verify libwolfssl.a is in the list. If not, click the "+", and on the "Choose frameworks and libraries to add:" dialog, click the button "Add other..." then find the file libwolfssl.a.
Click on the "Build Settings" tab. Scroll down to the section "Search Paths". Add the path to the include directory to the list "Header Search Paths".
When using FIPS
When using the FIPS version the following preprocessors need to be defined:
IPHONEHAVE_FIPSHAVE_HASHDRBGHAVE_AESGCMWOLFSSL_SHA512WOLFSSL_SHA384NO_MD4NO_DSANO_PWDBASED
The approved FIPS source files are from the CyaSSL project tag v3.4.8.fips. The files fips.c and fips_test.c, and the wolfCAVP test app are from the FIPS project tag v3.4.8a. The wolfSSL/wolfCrypt files are from tag v3.4.8.
Using the FIPS library
The FIPS library contains a self-check verify hash. Normally, on the desktop or server build, the library is built as a dynamic library. The library looks the same to every application that builds against it, and can be verified. For static libraries, when linking into your application, the addresses are all fixed, and the verify checksum becomes unusable. iOS does not allow dynamic libraries like this, so static builds are required. This creates a problem. Every time the application is changed, the FIPS checksum will change, because the FIPS library's position in the executable may change.
You need to add something to your application that will output the verifyCore value to be used. The verifyCore in fips_test.c will need to be updated with this value, the library rebuilt, and relinked into your application. The application should not be changed during this process or the verifyCore check will fail again.