Hey, @Kan_Li
Following up from CreateCryptoObject fails while doing sss_mac_init
While doing some stress testing, I witnessed wrong HMAC would return.
Further investigation revealed that if one process is killed while calling sss_mac_update()
Very next process would return wrong HMAC.
For example, see the code in the screenshot,

It will randomly kill the current process just after sss_mac_update, without cleanup. (Simulate systemd watchdog reset…)
The next hmac calculation gives wrong result without any error.
Digging into the source code, I see that CryptoObject is created inside sss_mac_init() and deleted inside sss_mac_context_free()
However, there is logic to reuse the context in sss_mac_init that is causing the issue.
There could be a way to disable this behavior. Instead of reusing, I want to be able to delete existing and create new CryptoObject everytime there is mac_init
Right now, I have implemented this workaround,

I am not sure if I should be using internal APIs or stick to first level sss_mac* APIs.
Summary.
- Should I use SSSFTR_SE05X_CREATE_DELETE_CRYPTOOBJ ? The documentation says I need to initialize all CryptoObject at time of provisioning. I don't think it will achieve what I am looking for
- Should I use my workaround and use internal APIs?
- I want to control this behavior programmatically (or via compile time if not possible programmatically), so a feature request for se05x dev team.
Edit: I tested SSS_FTR_SE05x_CREATE_DELETE_CRYPTOOBJ=0, it simply refuses to calculate hmac with init-update-finish. Which is not what I am looking for.