This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

AM263P4: Questions Regarding DTHE

Part Number: AM263P4

1. DTHE AES/HMAC API Usage and Key Management
The DTHE AES and HMAC APIs (DTHE_AES_execute() and DTHE_HMACSHA_compute()) require the symmetric key to be provided directly by the caller.
As implemented, this appears to require the symmetric key to be present in application memory and referenced directly by the software.
What is the intended usage model for these APIs?
For example, is there a recommended method to avoid handling the symmetric key directly in the application, such as using the HSM to securely manage or access the key material without exposing it to the application?

2. Concurrent Access to DTHE AES/HMAC APIs
If the DTHE AES and HMAC APIs are used from multiple cores and/or multiple tasks, is any software synchronization required?
In other words, are these APIs internally protected against concurrent access, or is it the application's responsibility to implement mutual exclusion (for example, a mutex or other locking mechanism) when accessing the DTHE hardware resources?

3. DTHE AES (Multi-Shot) and AES-CBC Final Block Handling
DTHE_AES_execute(..., DTHE_AES_STREAM_FINISH);
When using DTHE AES (Multi-Shot) for AES-CBC encryption, is it valid to call
with a streamSize that is not a multiple of 16 bytes?

The API documentation appears to indicate that this is supported.
If so:
- How is the final partial block processed during encryption?
- What data is actually generated in the encrypted output for the incomplete block?
- Does the same behavior apply during decryption?

Could you please explain the handling of partial blocks when DTHE_AES_STREAM_FINISH is used in AES-CBC mode?

Requested response date: September 25, 2026

  • Hi Makoto san,

    1. Yes, it is possible to store the key in HSM Flash and use the key for cryptographic operations also. 
    2. No internal synchronization exists in these APIs. It is the application's responsibility to implement mutual exclusion. Moreover, the same engine can't be used by multiple users with different contexts. For example: there could be 1 instance of AES and 1 instance of SHA but not 2 different instances/contexts of AES.
    3. Yes, a non-16-byte-aligned streamSize is explicitly allowed on FINISH. The 16-byte alignment check is only enforced for STREAM_UPDATE.
    - How is the final partial block processed during encryption?

    For CBC, the partial block is padded with zeroes till 16 bytes and subsequent operations are carried out on that like previous 16 byte aligned blocks.

    - What data is actually generated in the encrypted output for the incomplete block?

    The encrypted output is generated with the last block padded with zeroes till 16 byes.

    Does the same behavior apply during decryption?

    The full 16 bytes are decrypted also. So yes, the behavior is the same.

    Thanks and Regards,
    Aditya Singal