API to keep the key schedule in multi-part operation.

[tranvantruonggit]

Observation

Based on the current design of the multi-part operation, the following sequences setup -> update (n times) -> finish" are used to generate the result. Normally, the setup` operation will be the key schedule in the AES type of operation and it usually takes longer than single block encryption.

In the use case I worked with (specifically Secure Onboard Communication in automotive), they usually use CMAC to create the tag for the message, and the CMAC key leave for the whole session (usually a power cycle). The draw-back I saw with PSA's design is that we need to always call the setup operation in order to be able to update and finish to get the CMAC, otherwise, we will get the BAD_STATE error.

Proposal

My proposal is to have similar API to finish operation (for instance finish_and_reset), which return the result of the operation BUT still keep the operation state in the active and just reset everything else except for the key material inside the operation state variable.

This will look like this.

• The current sequence for CMAC compute for 2 messages:
  • Setup: key schedule (expensive operation)
  • Update: feed the first message
  • Finish: get the first MAC tag
  • Setup: key schedule 2nd time (expensive operation)
  • Update: feed the second message
  • Finish: get the second MAC tag
  • (and continue the loop of 3 operations)
• The proposed approach for CMAC compute for 2 messages:
  • Setup: key schedule (expensive operation)
  • Update: feed the first message
  • Finish_and_reset: get the first MAC tag and reset the state
  • Update: feed the second message
  • Finish_and_reset: get the second MAC tag and reset the state
  • (and continue the loop of 2 operations)

Other consideration

I see that there is the key policy PSA_KEY_USAGE_CACHE can be relevant to this, but it seems it is not intuitive for the multi-part operation.

[athoelke]

This is a use case that is similar to the one for which psa_hash_clone() was created. psa_hash_clone() duplicates a hash operation object, enabling two (or more) hashes using the same algorithm and prefix to be computed more efficiently.

I think I would prefer an API that was consistent with the hash operation to support the CMAC use case - a single 'reference' MAC operation object could be setup once. Then each CMAC computation first clones the reference object into a new MAC operation, and then computes the MAC as normal using the new operation object.

[athoelke]

Note, that although the psa_mac_clone() suggestion results in the same number of calls per MAC to the API as the current sequence:

• The computation cost of psa_mac_setup() is replaced by copying the operation state.
• The clone API is more flexible than a finish-and-reset API, as it can also be used to optimize computing MACs that have a common prefix, or successive MACs over an incrementally extending transcript, etc.

[tranvantruonggit]

Yes, if the clone was here, the same thing should be developed for Aead as well, or generally for all the xxx_operation_t.