[LinuxJedi]

Description

sp_int.c has fixed size multiply and square routines for 256-bit and 384-bit numbers (_sp_mul_4/6/8/12, _sp_sqr_4/6/8/12, with inline assembly on several CPUs) that speed up the generic ECC code. They are left out whenever WOLFSSL_HAVE_SP_ECC is defined, on the assumption that the SP code does the ECC work.

With WOLFSSL_SP_MATH_ALL that is not always true: the generic code still works on numbers of those sizes

• for curves the SP code does not implement, for example P-384 when only SP P-256 is built (--enable-sp=ec256, and on 32-bit CPUs --enable-sp=yes only gives P-256), or the Brainpool and Koblitz curves;
• for callers of the public mp API, for example hostapd/wpa_supplicant's WPA3-SAE, which does its field arithmetic with mp_* calls.

So enabling SP for one curve made the others slower than with no SP code at all. On a MIPS 24Kc at 650 MHz with --enable-sp=ec256:

Generic P-384	No SP	SP P-256, before	SP P-256, with this change
sign	113 ms	134 ms	113 ms
verify	74.5 ms	86.7 ms	73.0 ms

WPA3-SAE with hunting-and-pecking on P-256 (hostapd and wpa_supplicant from the same build, together with #11912) went from 337 ms to 314 ms per connection, and hostapd's CPU time from 228 ms to 202 ms.

This keeps the routines when WOLFSSL_SP_MATH_ALL is defined. WOLFSSL_SP_MATH builds and builds without SP ECC are unchanged. The cost is the code size of the routines in SP ECC + sp-math-all builds: on MIPS32 about 16 KB of library (about 2 KB compressed).

Testing

• ./tests/unit.test --api --group ecc and testwolfcrypt pass, on macOS arm64, with:
  • --enable-sp=ec256 --disable-sp-asm --enable-ecccustcurves=all
  • --enable-sp=ec256,ec384,ec521 --enable-sp-asm --enable-ecccustcurves=all
  • --enable-sp=smallec256,smallec384,smallec521 --disable-sp-asm --enable-ecccustcurves=all
  • --enable-sp-math --enable-sp=yes,384,521
  • --disable-sp --enable-ecccustcurves=all
• On MIPS 24Kc, with the same change on 5.9.4 (--enable-sp=ec256 and --enable-sp=ec256,ec384,ec521): testwolfcrypt passes, and the benchmark numbers above.

Checklist

• added tests
• updated/added doxygen
• updated appropriate READMEs
• Updated manual and documentation

[github-actions]

MemBrowse Memory Report

linuxkm-standard

• Data: __patchable_function_entries -16 B (-0.0%, 52,032 B)
  No memory changes detected for:
• gcc-arm-cortex-m0plus
• gcc-arm-cortex-m3
• gcc-arm-cortex-m4
• gcc-arm-cortex-m4-baremetal
• gcc-arm-cortex-m4-crypto-only
• gcc-arm-cortex-m4-dtls13
• gcc-arm-cortex-m4-min-ecc
• gcc-arm-cortex-m4-openssl-compat
• gcc-arm-cortex-m4-pkcs7
• gcc-arm-cortex-m4-pq
• gcc-arm-cortex-m4-rsa-only
• gcc-arm-cortex-m4-sp-math
• gcc-arm-cortex-m4-tls12
• gcc-arm-cortex-m4-tls13
• gcc-arm-cortex-m7
• gcc-arm-cortex-m7-pq
• gcc-arm-cortex-m7-tls13
• linuxkm-pie
• stm32-sim-stm32h753

[LinuxJedi]

@claude review

[claude]

I reviewed this PR and found no bugs. It turns on the unrolled and inline-asm multiply and square routines in builds that have both SP ECC and sp-math-all, a combination many default configurations use, so a human look at the core bignum arithmetic is still worthwhile.

What was reviewed:

• All four guard sites (the _sp_mul_* and _sp_sqr_* definitions and their dispatch in sp_mul()/sp_sqr()) use the same new condition, and the #endif comments match.
• The dangling else chains in sp_mul()/sp_sqr() keep the same structure. Only the outer condition changed, so every macro combination still produces a valid statement.
• No other uses of WOLFSSL_HAVE_SP_ECC or callers of these helpers in sp_int.c need to change with it.

Extended reasoning...

The change only edits four preprocessor conditions in wolfcrypt/src/sp_int.c. They now compile and dispatch to the fixed-size 256/384-bit multiply and square helpers (C and SQR_MUL_ASM variants) when WOLFSSL_HAVE_SP_ECC and WOLFSSL_SP_MATH_ALL are both defined. Each helper definition and its call site use the same guard, so no symbols go missing or unused. The change is crypto-sensitive: these routines will now do multiprecision arithmetic for generic ECC curves and public mp_* callers in builds that never ran them before, including timing-relevant inline assembly on several CPUs. That expanded runtime exposure in core crypto code is why I'm deferring to a human rather than approving.

[wolfSSL-Fenrir-bot]

Fenrir Automated Review — PR #11911

Scan targets checked: wolfcrypt-src, wolfcrypt-bugs
Coverage: 1 of 1 in-scope changed file(s) opened by the reviewer

Fenrir result: Approved ✅

No new issues found in the changed files.

Advisory only — this automated result does not count as a GitHub approval.

Review tier: Lite