Hi PSA Crypto Developer Forum,
I'm currently testing my PSA Crypto Driver integration on a hardware platform. Following the legacy test approach, I have built the Mbed TLS test suite with the PSA Crypto tests enabled, integrated the PSA Crypto Driver, and am cross-checking the results against those from the built-in software cipher implementations.
First, if this approach is not currently recommended for testing a PSA Crypto Driver integration on a hardware platform, I would appreciate any guidance on the recommended test methodology.
Regarding the Mbed TLS test suite approach, I'm currently investigating a failure in multipart testing. For example, the following test case fails: PSA symmetric encryption multipart: AES-ECB, 13+19 bytes .......... FAILED function_output_length == output1_length
With the built-in software implementation, when the first input is smaller than the AES block size (16 bytes) and is passed to mbedtls_cipher_update(), the input data is copied into the unprocessed_data buffer in the cipher context, and the cipher operation is deferred. When the second input is passed to mbedtls_cipher_update(), it is appended to the buffered data, allowing the combined data to be processed. However, with the PSA Crypto Driver API, I don't see any equivalent buffering of the first input. Instead, the data appears to be passed to the hardware accelerator on each call, regardless of whether the input size is smaller than the block size. Is this the expected behavior of the PSA Crypto Driver implementation for the multipart cipher operation?
If I ignore the output-length check for the update calls for both the first and second parts, the final result still does not match the expected result. This makes me suspect that I may be missing something in the way multipart operations are expected to be handled by the PSA Crypto Driver. I would appreciate any insight into how multipart operations should be implemented or tested in a PSA Crypto Driver, particularly for block ciphers such as AES-ECB.
Masaki Sato
________________________________
CONFIDENTIALITY NOTICE: This email and any attachments are for the sole use of the intended recipient(s) and contain information that may be Garmin confidential and/or Garmin legally privileged. If you have received this email in error, please notify the sender by reply email and delete the message. Any disclosure, copying, distribution or use of this communication (including attachments) by someone other than the intended recipient is prohibited. Thank you.
Hello,
On 01/09/2026 23:05, Sato, Masaki via psa-crypto wrote: (…)
With the built-in software implementation, when the first input is smaller than the AES block size (16 bytes) and is passed to mbedtls_cipher_update(), the input data is copied into the unprocessed_data buffer in the cipher context, and the cipher operation is deferred. When the second input is passed to mbedtls_cipher_update(), it is appended to the buffered data, allowing the combined data to be processed.
However, with the PSA Crypto Driver API, I don't see any equivalent buffering of the first input. Instead, the data appears to be passed to the hardware accelerator on each call, regardless of whether the input size is smaller than the block size.
Is this the expected behavior of the PSA Crypto Driver implementation for the multipart cipher operation?
As you've noted, the built-in implementation copies a partial block to the operation context, and only calls the AES processing function when it has a full block. This is part of the driver code, so you need to do the same buffering in your driver.
This buffering code is independent of the block cipher implementation, so we could do the buffering in the core, instead of requiring each driver to do it. We haven't done this because we did the core/driver split quickly for business reasons, so we generally chose the simplest architecture. Buffering in the core doesn't work for all modes or for all use cases, so it would be more complicated. But it is something we can consider.
Best regards,
psa-crypto@lists.trustedfirmware.org
-
Gilles Peskine -
Sato, Masaki