|SUCCESS| [10/10] app/test: add RSA-PSS sign and verify test cases

[dpdklab at iol.unh.edu]

Test-Label: ai-code-review
Test-Status: SUCCESS
https://dpdk.org/patch/168724

_AI Code Review_

=== Patch Review: series.patch (via Claude) ===
Review date: 2026-08-31

# DPDK Patch Review

## Patch 01/10: crypto: add RSA-specific capability parameters

### Errors

None.

### Warnings

None.

### Info

**Structure design observation:**
The patch adds `rte_crypto_rsa_capa` as a union member alongside existing fields like `modlen`, `internal_rng`, and `mldsa_capa`. This is a union, so only one field can be active at a time. For RSA transforms, code must use `rsa_capa.modlen` instead of the top-level `modlen` field. Consider documenting this transition clearly in the release notes--existing code reading `modlen` for RSA will need updates.

**Explicit salt feature note:**
The `pss_explicit_salt` field defaults to `false` (C zero-initialization), meaning PMDs that do not set it will correctly advertise no support for application-supplied salt. This is the safe default. Patches 2-6 do not set `pss_explicit_salt`, and patch 9 (OpenSSL PMD) explicitly rejects `pss_salt.data != NULL`, which is consistent with not advertising the capability.

---

## Patch 02/10: crypto/virtio: advertise RSA padding and hash capabilities

### Errors

None.

### Warnings

None.

### Info

The virtio PMD now reports padding and hash capabilities. The use of `RTE_BIT64()` for hash algorithm bitmasks is correct. The capabilities match the existing PKCS#1 v1.5 implementation (MD5, SHA-1, SHA-2 family).

---

## Patch 03/10: crypto/octeontx: advertise RSA PKCS#1 v1.5 padding support

### Errors

None.

### Warnings

None.

---

## Patch 04/10: crypto/cnxk: advertise RSA PKCS#1 v1.5 padding support

### Errors

None.

### Warnings

None.

---

## Patch 05/10: crypto/qat: advertise RSA padding capabilities

### Errors

None.

### Warnings

None.

### Info

The new `QAT_ASYM_RSA_CAP` macro follows the existing `QAT_ASYM_CAP` pattern. Both Gen1 and Gen4 PMDs advertise only `RTE_CRYPTO_RSA_PADDING_NONE`, which matches the QAT hardware's raw RSA capability.

---

## Patch 06/10: crypto/openssl: advertise RSA padding and hash capabilities

### Errors

None.

### Warnings

None.

### Info

The `#if (OPENSSL_VERSION_NUMBER >= 0x30000000L)` conditional advertising OAEP for OpenSSL 3.x is correct--older OpenSSL versions do not have EVP-level OAEP support in the PMD. The MGF1 and primary hash algorithm lists (SHA-1, SHA-2, SHA-3) match OpenSSL 3.x capabilities.

---

## Patch 07/10: crypto/openssl: add RSA-OAEP support for OpenSSL PMD

### Errors

None.

### Warnings

None.

### Info

**Resource management:**
- `openssl_set_asym_session_parameters()` allocates `sess->u.r.label` with `OPENSSL_zalloc()` and correctly frees it in the `err_rsa:` error path and in `openssl_reset_asym_session()`.
- `openssl_rsa_set_oaep_params()` calls `OPENSSL_memdup()` for the label and passes ownership to OpenSSL via `EVP_PKEY_CTX_set0_rsa_oaep_label()` (note the `0` in `set0`--this is a transfer-ownership call). On failure, it correctly frees the label before returning. This is proper OpenSSL memory semantics.

**Label length validation:**
The cast `(uint32_t)xform->rsa.padding.oaep_label.length` after checking `> INT_MAX` is safe--lengths up to `INT_MAX` fit in a `uint32_t`, and OpenSSL APIs accept `int` for label length. The `> INT_MAX` check prevents overflow of the OpenSSL API parameter.

**Design note:**
The PMD defaults `mgf1_md` to `oaep_md` when `xform->rsa.padding.mgf1hash` is zero. This matches the PKCS#1 v2.1 recommendation (MGF1 hash defaults to the same hash as OAEP unless explicitly specified). Patch 08 tests this with `rsa_oaep_labeled_default_mgf1_xform`.

---

## Patch 08/10: app/test: add RSA OAEP asymmetric test cases

### Errors

None.

### Warnings

None.

### Info

**Capability checking:**
The `rsa_oaep_supported()` helper correctly queries `rsa_capa.pad_types`, `hash_algos`, and conditionally `mgf1_hash_algos` (only when `mgf1hash` is explicitly set). The logic matches the API semantics: when `mgf1hash == 0`, the PMD falls back to the primary hash, so `mgf1_hash_algos` does not need checking.

**Test structure:**
Tests cover:
- Default OAEP (SHA-256, no label, MGF1 defaults to SHA-256)
- Custom MGF1 hash (SHA-1) with label
- Label with default MGF1 (verifies the fallback behavior)
- Both EXP and CRT private key types

The `queue_ops_rsa_enc_dec()` function (not shown in this patch but used by the tests) is the existing encrypt-then-decrypt validation path, reused for OAEP.

---

## Patch 09/10: crypto/openssl: add RSA-PSS support for RSA operations

### Errors

None.

### Warnings

None.

### Info

**Signature verification design:**
The patch introduces `openssl_rsa_pss_verify()` using `EVP_PKEY_verify()` instead of `EVP_PKEY_verify_recover()`. This is correct--RSA-PSS is a probabilistic signature scheme and does not support verify-recover (you cannot extract the original digest from the signature because of the random salt). The existing verify path is renamed to `openssl_rsa_verify_recover()` and remains for deterministic schemes (PKCS#1 v1.5, no padding).

**Return value semantics:**
- `openssl_rsa_pss_verify()` returns 0 for valid signature, 1 for invalid/mismatch, -1 for setup failure. This matches the documented OpenSSL `EVP_PKEY_verify()` behavior (1 = valid, 0 = invalid, <0 = error).
- The caller in `process_openssl_rsa_op_evp()` distinguishes between:
  - `ret < 0`: processing error, `goto err_rsa` (fail the op)
  - `ret > 0`: signature mismatch, `cop->status = RTE_CRYPTO_OP_STATUS_ERROR`, return 0 (op completes, but with error status)
  - `ret == 0`: success

This is correct. A signature mismatch is a normal outcome, not a processing failure.

**Unused `pss_explicit_salt` field:**
The PMD does not set `rsa_capa.pss_explicit_salt` (defaults to `false`), and `openssl_rsa_pss_sign()` rejects `op->rsa.pss_salt.data != NULL` with `INVALID_ARGS`. This is consistent with the API: the PMD does not advertise support for application-supplied salt, so it correctly rejects attempts to use it.

**MGF1 default handling:**
`openssl_set_asym_session_parameters()` defaults `mgf1_md` to `pss_md` when `xform->rsa.padding.mgf1hash == 0`. This matches PKCS#1 v2.1 and the same pattern used for OAEP in patch 07.

---

## Patch 10/10: app/test: add RSA-PSS sign and verify test cases

### Errors

None.

### Warnings

None.

### Info

**Salt length test coverage:**
The tests validate three salt length configurations:
- `pss_saltlen = 32` (digest length, SHA-256 hLen = 32)
- `pss_saltlen = 94` (maximum for 1024-bit key with SHA-256: emLen - hLen - 2 = 128 - 32 - 2 = 94)
- `pss_saltlen = 0` (deterministic PSS, no randomization)

The maximum salt length calculation is documented in the test vector comments and matches RFC 8017 section 9.1.1.

**Digest input:**
`rsa_pss_digest_sha256` is the SHA-256 digest of `rsaplaintext.data`. The tests correctly use this pre-computed digest as `rte_crypto_rsa_op_param::message` because `RTE_CRYPTO_RSA_PADDING_PSS` expects the message to already be hashed (matching the `padding.hash` algorithm), not the raw plaintext. The comment in the test code documents this.

**Sign-then-verify pattern:**
`queue_ops_rsa_pss_sign_verify()` signs a message, then verifies the just-generated signature. It does **not** include a corrupted-signature negative test (unlike the existing `queue_ops_rsa_sign_verify()` for PKCS#1 v1.5). This is because PSS verify uses `EVP_PKEY_verify()`, which returns pass/fail via the return value, not via verify-recover. The comment in the function documents this distinction.

**Capability checks:**
`rsa_pss_supported()` mirrors `rsa_oaep_supported()` and correctly checks `pad_types`, `hash_algos`, and conditionally `mgf1_hash_algos`. The skip messages are clear.

---

## Summary

**No errors found.** The patch series is well-structured and correct:

- API design: `rte_crypto_rsa_capa` cleanly reports RSA-specific capabilities (padding, MGF1 hash, salt support).
- PMD updates: virtio, octeontx, cnxk, qat, and openssl PMDs correctly advertise their capabilities.
- OpenSSL OAEP implementation: proper resource management, correct OpenSSL API usage, MGF1 default fallback.
- OpenSSL PSS implementation: correct separation of verify (PSS) vs verify-recover (deterministic schemes), proper handling of signature mismatch as a normal outcome.
- Test coverage: OAEP (default, custom MGF1, labeled) and PSS (digest-length salt, max salt, zero salt) cases, with proper capability checks and skip logic.
- Documentation: comments explain non-obvious design choices (digest input, MGF1 defaults, salt length calculations).

The series is ready for integration.