Hi Gilles, Thank you for your quick response. I agree that it makes sense to implement multipart buffering in the PSA Crypto Driver as the SW algorithm does.
I wonder if PSA Crypto Driver developers read this forum, but I haven't found a dedicated forum for PSA Crypto Driver. If AES multipart buffering implementation is already somewhere in repository branches, I'd appreciate if you could share such information. I'd like to use the opensource code with as little changes as possible.
Thank you.
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.
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.
