Files
wolfssl/IDE/Renesas/e2studio/SK-S7G2
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-12-20 10:32:09 +09:00
2026-02-18 09:52:21 -07:00
2025-12-20 10:32:09 +09:00
2025-12-20 10:32:09 +09:00
2025-12-24 06:36:08 +09:00
2025-12-24 05:59:09 +09:00

wolfSSL simple application projects for SK-S7G2 board

1. Overview


This repository provides simple sample applications for evaluating wolfSSL on the SK-S7G2 evaluation board (R7FS7G27H3A01CFC, S7G2 MCU). The samples run on Express Logic ThreadX (a real-time operating system) and use NetX/NetX Driver for networking and the SSP-provided drivers for the SK-S7G2 board.

The sample package includes applications that demonstrate the following functions:

  • Crypto Test: Automatically runs tests for various cryptographic operations.
  • Benchmark: Measures execution speed for various cryptographic operations. The benchmark also includes TCP and TLS client tests against a peer server.

Because the required hardware and software configurations for the evaluation board are already prepared, only minimal setup is needed to run the samples.

The following sections will walk you through the steps leading up to running the sample application.

2. Target H/W, components and libraries


This sample program uses the following hardware and software libraries. If a new version of any component is available, update it as appropriate.

item name & version
Board SK-S7G2 Starter Kit
Device R7FS7G27H3A01CFC
IDE Renesas e2Studio — Version: 2025-01 (25.1.0)
Toolchain GNU Arm Embedded Toolchain (arm-none-eabi-gcc), e.g. Arm GNU Toolchain 13.3.Rel1 (build arm-13.24)
SSP 2.7.0

The project includes a configuration file that references the following software components. These components are not bundled with this sample; you must download or install them via the e2studio Smart Configurator.

Component version
Board support package for R7FS7G27H3A01CFC 2.7.0
Board Support Packages 2.7.0
SSP Common Code 2.7.0
Clock Generation Circuit: Provides=[CGC] 2.7.0
Event Link Controller: Provides=[ELC] 2.7.0
Factory MCU Information Module: Provides=[FMI] 2.7.0
I/O Port: Provides=[IO Port] 2.7.0
S7G2_SK Board Support Files 2.7.0
Express Logic ThreadX: Provides=[ThreadX] 2.7.0
Secure Cryptography Engine: Provides=[TRNG, AES, HASH, RSA, DSA, TDES, ARC4, ECC, KEY_INSTALLATION] 2.7.0
Express Logic NetX Synergy Port: Provides=[NetX Driver], Requires=[NetX] 2.7.0
General Purpose Timer: Provides=[Timer, GPT] 2.7.0
Real Time Clock: Provides=[RTC] 2.7.0
Express Logic NetX: Provides=[NetX], Requires=[ThreadX, NetX Driver] 2.7.0

Note: Hardware-accelerated algorithms supported on this board (via the Secure Cryptography Engine / SSP):

  • True Random Number Generator (TRNG)
  • SHA-256
  • AES in ECB mode: AES-128, AES-192, AES-256

To use the hardware accelerators, enable the "Secure Cryptography Engine" component in the e2studio Smart Configurator and click "Generate Code". On the wolfSSL side, hardware SCE support is enabled with the WOLFSSL_SCE compile-time option. In this sample, WOLFSSL_SCE is defined in the user_settings.h file included in the wolfSSL_SKS7G2 project (for example: #define WOLFSSL_SCE), so the sample will use the Secure Cryptography Engine for the primitives listed above. To force software fallbacks for testing, remove the WOLFSSL_SCE define from user_settings.h or disable the Secure Cryptography Engine component.

3. Importing sample application project into e2Studio


There is no need to create a new project. Since the project file is already prepared, import the project from the IDE by following the steps below.

  • In e2studio: File > Open Project from File System... > Directory (R) ... Click the import source button and select the folder containing the project to import.
  • Four projects are listed for import. Select only the three projects: wolfbenchmark_test, wolfcrypt_test, and wolfssl_SKS7G2, then click Finish.

You should see the wolfbenchmark_test, wolfcrypt_test, and wolfssl_SKS7G2 projects in Project Explorer.

4. Smart configurator file generation


Follow the steps below:

  1. Open the wolfssl_SKS7G2 project in Project Explorer and double-click the configuration.xml file to open the Smart Configurator perspective.
  2. Click the "Generate Code" button in the Smart Configurator (top-right of the component settings pane) to generate the required source files. This creates a src/synergy_gen folder under the project.

5. Build and run wolfcrypt_test application


  1. Build the wolfssl_SKS7G2 project in Project Explorer, then build the wolfcrypt_test project.
  2. After a successful build, connect the target board to your PC via USB.
  3. Select Run > Debug to open the Debug perspective.
  4. The application outputs operating status to standard output. Keep the "Renesas Debug Virtual Console" open to view this output.
  5. Press the Run button to start the application.
  6. After displaying the crypto test result, the application enters an infinite loop. If output stops, stop debugging.

7. Running benchmark application


7.1 Prepare TCP server as a peer

The benchmark application includes a TCP client. You can use this TCP server application as the peer server.

$ gcc server-tcp.c -o server-tcp
$ ./server-tcp

You can modify the server IP address and port. Those are defined in app_entry.c based on your environment:

#define SERVER_IP IP_ADDRESS(192,168,3,10)
#define TLS_PORT 11112
#define TCP_PORT 11111

7.2 Prepare TLS server as a peer

The benchmark application also includes a TLS client. You can use the wolfSSL example TLS server as the peer server:

$ git clone https://github.com/wolfSSL/wolfssl.git
$ cd wolfssl
$ ./autogen.sh
$ ./configure
$ make
$ ./examples/server/server -bdi -p 11112 -v d

The -b option binds the server to all network interfaces (instead of localhost only). The -d option disables client authentication. The -i option makes the server loop indefinitely (allow repeated connections). The -p option sets the port number. The -v option sets the TLS version. The d value allows a downgrade to TLS 1.2 if a TLS 1.3 connection cannot be established.

7.3 Run benchmark application on the board

After building and running the benchmark on the board, the client connects to the server over TCP, exchanges a simple string, and prints output to the Renesas Debug Virtual Console similar to:

Pinging server to see if up .. got response from server
Benchmarking client TCP connection
Trying to connect to 0xC0A8030A on port 11111
100 TCP connections took 0.XXXXXX seconds

You will also see messages on the server console:

$ ./server-tcp
Waiting for a connection...
Client connected successfully
Client: Hello Server

Waiting for a connection...

For TLS benchmark, you will see messages like:

Benchmarking client TLSv1.2 connection using ECDHE-RSA-AES128-GCM-SHA256
Trying to connect to 0xC0A8030A on port 11112
100 TLS connections took YYY.XXXXXX seconds (and ZZZ.XXXXXX tx_time ticks)

Benchmarking client TLSv1.3 WOLFSSL_ECC_X25519 connection using TLS13_AES128_GCM_SHA256
Trying to connect to 0xC0A8030A on port 11112
100 TLS connections took YYY.XXXXXX seconds (and ZZZ.XXXXXX tx_time ticks)

Benchmarking client TLSv1.3 WOLFSSL_ECC_SECP256R1 connection using TLS13_AES128_GCM_SHA256
Trying to connect to 0xC0A8030A on port 11112
100 TLS connections took YYY.XXXXXX seconds (and ZZZ.XXXXXX tx_time ticks)

Benchmarking client TLSv1.3 WOLFSSL_FFDHE_2048 connection using TLS13_AES128_GCM_SHA256
Trying to connect to 0xC0A8030A on port 11112
100 TLS connections took YYY.XXXXXX seconds (and ZZZ.XXXXXX tx_time ticks)

On the server console you may see:

$ ./examples/server/server -bdi -p 11112 -v d
listening on port 11112
SSL version is TLSv1.2
SSL cipher suite is TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
SSL curve name is SECP256R1
...
SSL version is TLSv1.3
SSL cipher suite is TLS_AES_128_GCM_SHA256
SSL curve name is X25519
...
SSL version is TLSv1.3
SSL cipher suite is TLS_AES_128_GCM_SHA256
SSL curve name is SECP256R1
...
SSL version is TLSv1.3
SSL cipher suite is TLS_AES_128_GCM_SHA256
SSL curve name is FFDHE_2048

Finally, the application runs cryptographic benchmarks. You will see output like:

wolfCrypt Benchmark (block bytes 1024, min 1.0 sec each)
...
Benchmark complete

8. Support


For support inquiries, email support@wolfssl.com. For Japanese support, contact info@wolfssl.jp.