|WARNING| [v3,2/2] crypto/ipsec_mb: Add SHAKE support.

[dpdklab at iol.unh.edu]

Test-Label: ai-code-review
Test-Status: WARNING
https://dpdk.org/patch/171125

_AI Code Review_

=== Patch Review: series.patch (via Claude) ===
Review date: 2026-10-13

# DPDK Patch Review

## ERRORS

None.

## WARNINGS

### Patch 1/2: crypto/ipsec_mb: Add SHA3 support

**1. Hardcoded pad buffer size in comment may become stale**

File: `drivers/crypto/ipsec_mb/pmd_aesni_mb_priv.h`  
Lines: 1252-1260

The comment claims the maximum pad size is "144 bytes for SHA3-224", but the buffer is declared as 144 bytes. SHA3-224's block size is indeed 144 bytes, making this the current maximum among the supported algorithms. However, if a future algorithm with a larger block size is added, the comment and buffer size would both need updating. Consider whether the comment should reference a computed maximum or simply state the current allocation size without claiming it is "the maximum supported."

Current code:
```c
alignas(16) uint8_t inner[144];
/* *< inner pad */
alignas(16) uint8_t outer[144];
/* *< outer pad */
} pads;
/* *< HMAC Authentication pads -
 * allocating space for the maximum pad
 * size supported which is 144 bytes for
 * SHA3-224
 */
```

Suggested: Update the comment to be more maintainable:
```c
/* *< HMAC Authentication pads -
 * currently sized for SHA3-224 block size (144 bytes)
 */
```

This is a documentation clarity issue, not a functional defect.

### Patch 2/2: crypto/ipsec_mb: Add SHAKE support

**1. SHAKE digest size max values may be incorrect**

File: `drivers/crypto/ipsec_mb/pmd_aesni_mb_priv.h`  
Lines: 957, 976

The SHAKE-128 and SHAKE-256 capabilities declare `.digest_size.max = 64`, but SHAKE algorithms are extendable-output functions (XOFs) that can produce arbitrary-length output. The current implementation caps both at 64 bytes, which may be an artificial limitation imposed by the intel-ipsec-mb library or by the internal buffer sizing.

If the intel-ipsec-mb library supports larger output lengths, the capability should reflect that. If 64 bytes is truly the maximum supported by the library, this is acceptable but should be verified against the library documentation.

Current code:
```c
.digest_size = {
	.min = 1,
	.max = 64,
	.increment = 1
},
```

Action: Verify that 64 bytes is the correct maximum supported by intel-ipsec-mb v3.0.0+ for SHAKE-128 and SHAKE-256. If the library supports larger outputs, update the `.max` value accordingly.

**2. SHAKE truncated digest lengths set to 64 may not match typical usage**

File: `drivers/crypto/ipsec_mb/pmd_aesni_mb_priv.h`  
Lines: 1164-1165

The `auth_truncated_digest_byte_lengths` array sets both SHAKE-128 and SHAKE-256 to 64 bytes. For SHAKE-128, the typical security-equivalent output length is 128 bits (16 bytes), and for SHAKE-256 it is 256 bits (32 bytes), matching their security levels. Setting the truncated length to 64 bytes for both may not align with common use cases or NIST recommendations (SP 800-185).

If this value represents the driver's default or maximum truncated length rather than a security-level-appropriate default, it should be documented. Otherwise, consider whether the truncated lengths should be 16 and 32 bytes respectively.

Current code:
```c
[IMB_AUTH_SHAKE128]		= 64,
[IMB_AUTH_SHAKE256]		= 64
```

Suggested values (if aligning with security level):
```c
[IMB_AUTH_SHAKE128]		= 16,
[IMB_AUTH_SHAKE256]		= 32
```

However, if the intel-ipsec-mb library or the driver design intentionally uses 64 bytes as the default/truncated length, document this choice.

---

Review-Result: WARNING