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,

-- 
Gilles Peskine
TF-PSA-Crypto developer