Fix ML-DSA MakePublicKey derivation, verify guards, and ASN derivation testing

[stenslae]

Description

This update introduces automatic derivation of the ML-DSA public key from the private key during parsing if the public key data is missing.

wolfSSL/wolfssh#1120

Testing

Added test coverage.

Checklist

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

[github-actions]

retest this please

[github-actions]

MemBrowse Memory Report

gcc-arm-cortex-m0plus

• FLASH: .text +24 B (+0.0%, 64,231 B / 262,144 B, total: 25% used)

gcc-arm-cortex-m3

• FLASH: .text +20 B (+0.0%, 122,559 B / 262,144 B, total: 47% used)

gcc-arm-cortex-m4-baremetal

• FLASH: .text +64 B (+0.1%, 66,891 B / 262,144 B, total: 26% used)

gcc-arm-cortex-m4-min-ecc

• FLASH: .text +64 B (+0.1%, 61,805 B / 262,144 B, total: 24% used)

gcc-arm-cortex-m4-pq

• FLASH: .text +448 B (+0.2%, 280,448 B / 1,048,576 B, total: 27% used)

gcc-arm-cortex-m4-sp-math

• FLASH: .text +64 B (+0.1%, 61,805 B / 262,144 B, total: 24% used)

gcc-arm-cortex-m4-tls12

• FLASH: .text +64 B (+0.1%, 123,355 B / 262,144 B, total: 47% used)

gcc-arm-cortex-m7-pq

• FLASH: .text +448 B (+0.2%, 281,024 B / 1,048,576 B, total: 27% used)

linuxkm-pie

• Data: __patchable_function_entries +8 B (+0.0%, 25,968 B)

linuxkm-standard

• Data: __patchable_function_entries +16 B (+0.0%, 48,632 B)
  No memory changes detected for:
• gcc-arm-cortex-m4
• gcc-arm-cortex-m4-crypto-only
• gcc-arm-cortex-m4-dtls13
• gcc-arm-cortex-m4-openssl-compat
• gcc-arm-cortex-m4-pkcs7
• gcc-arm-cortex-m4-rsa-only
• gcc-arm-cortex-m4-tls13
• gcc-arm-cortex-m7
• gcc-arm-cortex-m7-tls13
• stm32-sim-stm32h753

[wolfSSL-Fenrir-bot]

Fenrir Automated Review — PR #10985

Scan targets checked: wolfcrypt-bugs, wolfcrypt-rs-bugs, wolfcrypt-src, wolfssl-bugs, wolfssl-src

Findings: 1
1 finding(s) posted as inline comments (see file-level comments below)

This review was generated automatically by Fenrir. Findings are non-blocking.

[wolfSSL-Fenrir-bot]

🟠 [Medium] Memory leak in wc_MlDsaKey_MakePublicKey when WC_MLDSA_CACHE_PRIV_VECTORS is defined · Resource leaks on error paths

The cleanup block that calls XFREE(s1, ...) is gated #ifndef WC_MLDSA_CACHE_PRIV_VECTORS, but when that macro is defined without WC_MLDSA_FIXED_ARRAY, XMALLOC is still called into local s1 (didAlloc=1): in non-small-mem mode line 10399 adds aSz to allocSz; in small-mem mode lines 10403-10406 always include s1/s2/t sizes regardless of the macro. The allocation is never freed.

Fix: Add a matching if (didAlloc) { XFREE(s1, key->heap, DYNAMIC_TYPE_MLDSA); } inside a #ifdef WC_MLDSA_CACHE_PRIV_VECTORS block, or restructure so didAlloc always drives a single free regardless of the macro.