[keymgr, kmac] Context Switch (save/restore)

Discussed with Software ppl about the context switch feature in KMAC, which software can save current hashing engine state and restore later after processing urgent requests like KeyMgr KDF. General consensus is that the KeyMgr KDF should not be interrupted by other context as it shall be atomic. But the software context may be interrupted by other urgent software task or KeyMgr KDF.

To support context switch, KMAC/ SHA3 should be able to expose whole 1600bit (double in case of masking) and let software restore the keccak state later. Exposing 1600bit of state is supported at this moment but restoring 1600bit is not supported yet. SHA3 core only let the software to write up to a block rate size (1600-capacity). The revision, however, is relatively simple unless it is in the middle of KMAC or cSHAKE operation. Software ppl agreed that KMAC/cSHAKE won't have long enough message. So we can opt out that case.

At this moment, however, software's main hashing algorithm is HMAC/SHA2 not SHA3. So utilization of SHA3 won't that high for foreseeable future and relative low chance of collision it will have. So, decided not to support context switch feature in KMAC/SHA3 but will measure the effort to support context switch feature in HMAC/SHA2 after current milestone is reached.

The issue discusses context switching for KMAC/SHA3 and a possible future effort for HMAC/SHA2, but names no files, tests, or implementation entry points. First clarify whether context switching is still wanted and define the target algorithm and scope; done would require an agreed design and corresponding implementation and verification plan.

Written by the indexing model from the issue text.