You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Adds ESP32-C5 hardware acceleration to the Espressif port:
AES-128/256 (ECB/CBC/CTR/OFB/CFB/GCM/XTS/SIV/EAX as exposed by wolfCrypt)
SHA-1, SHA-224, SHA-256, SHA-384, SHA-512, SHA-512/224 and SHA-512/256
RSA/MPI multiply, multiply-modulo and exponentiation
Generic ECC point multiplication for SECP192R1, SECP256R1 and SECP384R1
Transparent ECDSA verification using the dedicated ECDSA engine
Opaque ECDSA signing and public-key export with eFuse or Key Manager keys
through the ESP-IDF PSA drivers
The C5 uses the ESP-IDF 6.x esp_crypto_* clock helpers; the C6 keeps its
ESP-IDF 5.x register path. SHA-512 family reads the complete 512-bit chaining
state, converts it to native 64-bit words and preserves it across copies.
SHA-224 finalization releases an unfinished engine lock.
Opaque keys fail closed: private-key export, key generation, ECDH and any
software fallback are rejected, and a reused ecc_key has its stale software
scalar destroyed when an opaque key is bound. eFuse provisioning is not part of
the library - wc_esp32_ecdsa_use_efuse_key() only binds an already-provisioned
key and never writes eFuse.
The test example gains optional, default-disabled self-tests for SHA active
copies, eFuse ECDSA and Key Manager ECDSA. The Key Manager test deploys a
throwaway random key without NVS or eFuse writes.
Enable the ESP32-C5 SHA, AES and RSA/MPI engines, add SECP192R1/256R1/384R1 point multiplication with transparent ECDSA verification, and add eFuse/Key Manager opaque ECDSA signing with public-key export.
The C5 uses the ESP-IDF 6.x crypto clock helpers while C6 retains its 5.x register path. Opaque keys never expose private material: private export, key generation, ECDH and software fallback are rejected.
SHA-512 family reads the full 512-bit chaining state and converts it to native 64-bit words, and SHA copies capture the complete state so hardware contexts can continue in software. SHA-224 finalization releases an unfinished engine lock.
Add the ESP32-C5 target to the ESP-IDF example components, user_settings templates and the platform documentation. The test example ships C5 sdkconfig defaults that enable the opaque ECDSA PSA drivers and a software-only variant used to validate the SW fallback.
Add an IDF v6.1 ESP32-C5 CI job. Component dependencies now include esp_security and mbedtls where available and use version-gated esp_driver_uart and esp_driver_gptimer components, keeping IDF 4.4 support intact.
Add optional, default-disabled self-tests for the ESP32-C5 SHA copy path, an eFuse ECDSA key and a Key Manager key. The eFuse test only binds an already-provisioned throwaway key and never writes eFuse; the Key Manager test deploys a random key without NVS or eFuse writes.
Document the three test options in the Espressif port README.
Gate the split esp_driver_uart and esp_driver_gptimer components on ESP-IDF 5.3, where they were introduced, and keep the driver component for older 5.x releases.
Include the ECC/ECDSA declarations when either acceleration flag is set, so NO_WOLFSSL_ESP32_CRYPT_ECC builds still see the verification prototype.
Honor CONFIG_ESP_WOLFSSL_NO_ESP32_CRYPT before any C5 target flags are derived, and keep the opaque ECDSA flag disabled for software-only builds. Guard the truncated SHA-512 variants and C5 chaining-state sizes so SHA-1/SHA-256-only and SHA-384/SHA-512-only configurations compile.
Thanks for the review. All six items are addressed in fccebdd8c8:
esp_driver_gptimer version guard — the split component is now selected only for ESP-IDF >= 5.3 in the template, benchmark, client, server and test component CMakeLists.txt. Older 5.x keeps driver, which still exports the GPTimer API.
esp_driver_uart version guard — main/CMakeLists.txt now uses driver for ESP-IDF 5.0–5.2 and esp_driver_uart from 5.3.
ECC/ECDSA declaration — wolfcrypt/src/ecc.c includes esp32-ecc.h when either WOLFSSL_ESP32_CRYPT_ECC or WOLFSSL_ESP32_CRYPT_ECDSA is defined, so NO_WOLFSSL_ESP32_CRYPT_ECC builds still see esp32_ecdsa_verify_hash().
Truncated SHA-512 variants — the SHA-512/224 and SHA-512/256 digest sizes are gated on WOLFSSL_SHA512 and the corresponding WOLFSSL_NOSHA512_* switch.
C5 reduced configurations — the SHA-224 state size is guarded by !NO_SHA256 and the 512-bit state handling by WOLFSSL_SHA384 || WOLFSSL_SHA512, so SHA-1/SHA-256-only and SHA-384/SHA-512-only builds compile.
Software-only Kconfig ordering — CONFIG_ESP_WOLFSSL_NO_ESP32_CRYPT now defines NO_ESP32_CRYPT before any target flags are derived in esp32-crypt.h, and the opaque ECDSA flag in settings.h also checks the Kconfig switch. The sdkconfig.sw build no longer contains wc_esp32_ecdsa_use_efuse_key or esp32_ecc_mulmod symbols.
Re-validated after the changes:
ESP32-C5 v1.2, ESP-IDF v6.1 full suite: exit code 0, no SHA lock warnings.
The reason will be displayed to describe this comment to others. Learn more.
🔵 Needs a closer look
Initialization-failure cleanup can free an uninitialized context, while SHA-224 cleanup can leave the FreeRTOS SHA mutex locked and force subsequent hashes into software.
No open issues 🎉
2 previously missed issues
In code that hasn't changed since last review
Avoid freeing contexts after initialization failure
If the source initializer fails (for example, an allocation failure with WOLFSSL_SMALL_STACK_CACHE), the destination initializer is skipped, but the macro still calls FREE(&dst) unconditionally. Those free routines inspect fields such as W, so this can wipe or free an indeterminate pointer instead of reporting the initialization error. Exit this test iteration on initialization failure, freeing only contexts that initialized successfully.
Unlock the SHA mutex when freeing a same-task context
wolfcrypt/src/sha256.c:3330
With the default FreeRTOS task-lock monitoring enabled, freeing a SHA-224 context after processing a full block still leaves the SHA mutex held: the helper's same-task branch only logs instead of unlocking. Cleanup clears the owner and discards the context, leaving subsequent hashes to fall back to software. Update esp_sha_release_unfinished_lock() in esp32_sha.c to unlock in the same-task branch while preserving cross-task ownership handling.
Free only self-test hash contexts whose initialization succeeded, so an allocation failure cannot free an indeterminate destination context.
When ESP_MONITOR_HW_TASK_LOCK is enabled, the owning task now actually releases an unfinished SHA lock instead of only logging, while a different task still leaves the ESP32_SHA_FREED hint for the owner. This prevents subsequent hashes from falling back to software after wc_Sha224Free().
Both previously missed issues are fixed in 4b6717b4b5:
Self-test cleanup after initialization failure — C5_SHA_COPY_TEST now tracks srcInit/dstInit and only calls FREE() on contexts that initialized successfully. A failed INIT(&src) no longer leads to FREE(&dst) on an indeterminate context.
Same-task SHA unlock — esp_sha_release_unfinished_lock() now calls esp_sha_hw_unlock(ctx) when ctx->task_owner is the current task under ESP_MONITOR_HW_TASK_LOCK; a different task still sets the ESP32_SHA_FREED hint for the owner.
Validation:
ESP32-C5 v1.2, ESP-IDF v6.1 with WOLFSSL_ESP32C5_TEST_SHA_COPY enabled: SHA copy self-test returns 0 and the full suite exits 0.
The non-SINGLE_THREADED configuration (where the task-owner branch is compiled) builds successfully.
The reason will be displayed to describe this comment to others. Learn more.
🔵 Needs a closer look
The new logging statement breaks compilation on supported ESP32-C3/ESP-IDF 4.4 configurations, while ECC binding and hardware-dispatch mismatches can use inconsistent curves or reject valid points.
No open issues 🎉
3 previously missed issues
In code that hasn't changed since last review
Use the legacy C3 CPU-frequency macro with ESP-IDF 4.4
On ESP32-C3 with the still-supported ESP-IDF 4.4, the CPU-frequency setting is CONFIG_ESP32C3_DEFAULT_CPU_FREQ_MHZ, not CONFIG_ESP_DEFAULT_CPU_FREQ_MHZ. This newly enabled logging statement therefore fails to compile that target. Please guard the generic macro's availability or retain a legacy-C3 branch, as esp32_util.c already does.
Prevent hardware dispatch for curves with mismatched coefficients
wolfcrypt/src/port/Espressif/esp32_ecc.c:144
Matching only the prime and A selects SECP192R1 hardware for PRIME192V2 and PRIME192V3, which share those values but have different B coefficients (wolfcrypt/src/ecc.c:1157–1207). Their valid points are rejected with IS_POINT_E, so the callers never reach the software fallback; custom curves sharing a supported curve's prime and A have the same problem. Check point membership in the selected hardware curve, or pass the full curve identity into dispatch, and return NOT_COMPILED_IN for unsupported curves.
Reject custom or mismatched curves before hardware key binding
Both binding APIs call wc_ecc_set_curve(), which preserves existing custom domain parameters when key->idx == ECC_CUSTOM_IDX. Reusing such a key can therefore bind a hardware R1 key while signing and verification/export use different curves. Reject custom or mismatched domain parameters before binding, or explicitly replace them safely.
Fix C3 legacy CPU frequency handling and IDF 5.3 component guards. Make ECC fall back to software for mismatched curves, reject custom opaque-key bindings, and preserve keys after invalid curve changes. Align SHA lock ownership and reduced configurations, avoid ECDSA/KM lock inversion, and gate C5 acceleration to IDF 6.x. Add optional SHA lock and ECC curve hardware self-tests.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
Adds ESP32-C5 hardware acceleration to the Espressif port:
through the ESP-IDF PSA drivers
The C5 uses the ESP-IDF 6.x
esp_crypto_*clock helpers; the C6 keeps itsESP-IDF 5.x register path. SHA-512 family reads the complete 512-bit chaining
state, converts it to native 64-bit words and preserves it across copies.
SHA-224 finalization releases an unfinished engine lock.
Opaque keys fail closed: private-key export, key generation, ECDH and any
software fallback are rejected, and a reused
ecc_keyhas its stale softwarescalar destroyed when an opaque key is bound. eFuse provisioning is not part of
the library -
wc_esp32_ecdsa_use_efuse_key()only binds an already-provisionedkey and never writes eFuse.
The test example gains optional, default-disabled self-tests for SHA active
copies, eFuse ECDSA and Key Manager ECDSA. The Key Manager test deploys a
throwaway random key without NVS or eFuse writes.
Fixes N/A (new platform support).
Testing
Hardware: ESP32-C5, revision v1.2, ESP-IDF v6.1, COM6.
wolf_test_tasksuite passes on the default configuration; exit code 0.rejection: 0
rejection: 0
point multiplication and ECDSA verification.
BLOCK_KEY0was confirmed empty withespefuse.py summary; only athrowaway P-256 key was provisioned for the eFuse test.
(
CONFIG_ESP_WOLFSSL_NO_ESP32_CRYPT), and the benchmark, client and serverexamples.
working through version gating.
Checklist
A contributor agreement request will be sent to support@wolfssl.com referencing
this PR.