[kareem-wolfssl]

Description

Testing

Built-in + added tests

Checklist

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

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has insufficient remaining quota.

[kareem-wolfssl]

@claude review

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has insufficient remaining quota.

[github-actions]

MemBrowse Memory Report · Explore what changed →

gcc-arm-cortex-m0plus

• FLASH: .text +148 B (+0.2%, 70,827 B / 262,144 B, total: 27% used)

gcc-arm-cortex-m3

• FLASH: .text +356 B (+0.3%, 131,781 B / 262,144 B, total: 50% used)

gcc-arm-cortex-m4

• FLASH: .text +604 B (+0.3%, 209,036 B / 262,144 B, total: 80% used)

gcc-arm-cortex-m4-baremetal

• FLASH: .text +192 B (+0.3%, 73,527 B / 262,144 B, total: 28% used)

gcc-arm-cortex-m4-crypto-only

• FLASH: .text +128 B (+0.1%, 181,715 B / 262,144 B, total: 69% used)

gcc-arm-cortex-m4-dtls13

• FLASH: .text +896 B (+0.5%, 195,992 B / 1,048,576 B, total: 19% used)

gcc-arm-cortex-m4-min-ecc

• FLASH: .text +128 B (+0.2%, 68,121 B / 262,144 B, total: 26% used)

gcc-arm-cortex-m4-openssl-compat

• FLASH: .rodata +2,472 B, .text +2,112 B (+0.6%, 801,508 B / 1,048,576 B, total: 76% used)
• RAM: .bss -12,048 B (-9.0%, 121,772 B / 262,144 B, total: 46% used)

gcc-arm-cortex-m4-pkcs7

• FLASH: .text +192 B (+0.1%, 222,868 B / 262,144 B, total: 85% used)

gcc-arm-cortex-m4-pq

• FLASH: .text +1,024 B (+0.3%, 312,848 B / 1,048,576 B, total: 30% used)

gcc-arm-cortex-m4-rsa-only

• FLASH: .rodata +8 B, .text +1,024 B (+0.3%, 343,696 B / 1,048,576 B, total: 33% used)
• RAM: .bss +1,320 B (+7.9%, 17,996 B / 262,144 B, total: 7% used)

gcc-arm-cortex-m4-sp-math

• FLASH: .text +128 B (+0.2%, 68,121 B / 262,144 B, total: 26% used)

gcc-arm-cortex-m4-tls12

• FLASH: .text +384 B (+0.3%, 132,561 B / 262,144 B, total: 51% used)

gcc-arm-cortex-m4-tls13

• FLASH: .text +896 B (+0.4%, 249,634 B / 262,144 B, total: 95% used)

gcc-arm-cortex-m7

• FLASH: .text +668 B (+0.3%, 209,100 B / 262,144 B, total: 80% used)

gcc-arm-cortex-m7-pq

• FLASH: .text +1,024 B (+0.3%, 313,680 B / 1,048,576 B, total: 30% used)

gcc-arm-cortex-m7-tls13

• FLASH: .text +832 B (+0.3%, 249,634 B / 262,144 B, total: 95% used)

stm32-sim-stm32h753

• FLASH: .text -512 B (-0.3%, 204,076 B / 2,097,152 B, total: 10% used)

zephyr-frdm_rw612

• FLASH: datas +16 B, text +2,088 B (+0.7%, 286,152 B / 67,108,864 B, total: 0% used)
• RAM: bss +49 B, datas +16 B (+0.1%, 58,423 B / 983,040 B, total: 6% used)

---

_{Catch memory regressions in CI with MemBrowse. Free for open source.}

[claude]

Nothing blocking. The comments below are optional suggestions. There is no need to push a fix for them before merging.

Additional findings (outside the current diff — GitHub can't attach inline comments there):

• 🟣 wolfcrypt/src/port/ti/ti-aes.c — Pre-existing: on TI, a hardware failure in the main AES-GCM/CCM encrypt path is still reported as AES_GCM_AUTH_E, even in CCM mode. This change makes the other paths return WC_HW_E or a mode-correct code, so encrypt is now the inconsistent one. Fix: return WC_HW_E when ROM_AESDataProcessAuth returns false in AesAuthEncrypt. That matches the new early-path handling at ti-aes.c:617-625 and keeps the existing ForceZero of out and authTag.

  Why this was flagged

  AesAuthEncrypt (ti-aes.c:577) is reached via wc_AesGcmEncrypt, wc_AesCcmEncrypt and GMAC. When ROM_AESDataProcessAuth returns false (ti-aes.c:667-674), the code sets ret = AES_GCM_AUTH_E at ti-aes.c:679 regardless of mode. Encryption has no authentication to fail, so this is an engine failure. In the same function this PR now returns WC_HW_E for an engine failure in the empty-input path (ti-aes.c:617-625). In AesAuthDecrypt it now picks AES_CCM_AUTH_E for CCM at ti-aes.c:808. So a CCM caller on TI hardware gets an AES-GCM authentication error for a hardware fault, and the error depends on which branch ran. The base behaved the same way (pre-existing). This PR's partial fix leaves this sibling path inconsistent.

  Verification: Pre-existing. In AesAuthEncrypt (wolfcrypt/src/port/ti/ti-aes.c:668-680), when ROM_AESDataProcessAuth returns false, the code still returns AES_GCM_AUTH_E whatever the mode. That includes CCM. This PR changes the empty-input path (lines 617-625) to return WC_HW_E, and AesAuthDecrypt now picks the code by mode at line 808. The harm is limited because out and authTag are zeroed (lines 676-678), and the base branch already returns this code.

• 🟣 wolfcrypt/src/port/ti/ti-aes.c — pre-existing: TI AES-GCM callers with a non-12-byte nonce can still get an IV derived from an uninitialized subkey if the hardware call fails. The PR checks ROM_AESDataProcess elsewhere but not at ti-aes.c:476 in AesAuthSetIv. If that call fails, subkey is never written and is still loaded via ROM_AESKey2Set to GHASH the nonce. Fix: check the result at ti-aes.c:476 and return WC_HW_E. This means AesAuthSetIv must return int, and AesAuthEncrypt/AesAuthDecrypt must pass that error up, the same way AesAlign16 now does.

  Why this was flagged

  The trigger is wc_AesGcmEncrypt/Decrypt on TI hardware with a nonce length other than GCM_NONCE_MID_SZ, which reaches the else branch of AesAuthSetIv (ti-aes.c:462). The trigger also needs ROM_AESDataProcess to return false at ti-aes.c:476. The stack array subkey (ti-aes.c:464) is then still uninitialized. It is passed to ROM_AESKey2Set at ti-aes.c:481, so the J0 counter written to aes->reg comes from whatever was on the stack. Encryption then goes ahead and reports success with a wrong tag and keystream, with no error to the caller. Different nonces could even map to the same counter. This PR adds checks with the same purpose at AesAlign16 (ti-aes.c:165) and at both empty-input tag paths (ti-aes.c:617, 745), so this sibling is the one ROM_AESDataProcess call left unchecked. The base has the same behaviour here.

  Verification: pre-existing. Trigger: TI GCM with a nonce length other than GCM_NONCE_MID_SZ, and ROM_AESDataProcess returning false. ROM_AESDataProcess(AES_BASE, zeros, subkey, sizeof zeros); (wolfcrypt/src/port/ti/ti-aes.c:476) ignores its bool result, and ROM_AESKey2Set(AES_BASE, subkey, ...) (line 481) then loads whatever subkey holds. The base already behaves the same way by the same route.

[Copilot]

🟡 Changes recommended

Active issues remain: the API documentation omits required BAD_FUNC_ARG conditions, and the Xilinx AES-GCM encryptor now permits short tags that the decryptor neither supports nor safely handles.

3 open issues

• Keep Xilinx GCM encryption tag size fixed until decrypt supports short tags · New
• Retain BAD_FUNC_ARG documentation for invalid decode arguments · New
• Document BAD_FUNC_ARG for NULL input with nonzero length · New

_{Review effort: Lite}

[kareem-wolfssl]

Master currently accepts any size from 0-16 bytes, so this is tightening the accepted range. The software implementation currently allows 12–16 bytes. IMO it doesn't make sense for this to be stricter, even if the HW decrypt doesn't accept 12-15 bytes currently.