You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Consider whether we want to have a timeout value for polling for interrupt signal. HMAC does not use EDN, so we should be able to determine a reasonable timeout value. -> [hmac, sw] Revert hash stop hang workaround #25594
Use a random 32-bit values from EDN to wipe HMAC, instead of fixed 32'b1. We can read a value from RV_CORE_IBEX_RND_STATUS_REG_OFFSET.
Write message bits in 32-bit blocks instead of 8-bit blocks, as much as possible.
Determine if we need to handle back-pressure when SW is writing too many message bytes in a row without a break. (We probably do not need this because there is no asynchronous EDN interaction in HMAC, unlike KMAC.)
Implement oneshot driver calls and connect them to cryptolib functions.
Revisit docs of driver functions and improve its quality (i.e. there might be missing parameters in the comment blocks, or the current descriptions might not be explaining what the caller needs to do).
Remove old sha256/sha512 files related to OTBN.
For programmer's guide: add a line stating that during streaming, SW can only feed message blocks that are multiples of internal block size. What is missing is 0 block feeding is not allowed, there needs to be at least one block.
And potential improvement suggestions for SCA/FI hardening:
Use randomized copying (similar to hardened_memcpy) for KEY and DIGEST registers. This can also be extended to message inputs if message bits are also sensitive, depending on the use case (e.g. HMAC-DRBG).
Use multi-bit encoding for hw_started flag.
Determine if cleaning the values of ctx after the final call makes sense. If so, the values could be populated with random values. The suggestion is to zeroise or randomly populate ctx struct during init.
Improve copying function between otcrypto and driver ctx structs, by copying at word granularity.
The following is addressed by both of these PRs (once merged): #24839 and #24944
"Consider whether we want to have a timeout value for polling for interrupt signal. HMAC does not use EDN, so we should be able to determine a reasonable timeout value."
The previously reverted commit f591bea (later refined in e869152)
contained a desirable timeout implementation for the HMAC idle
polling (see lowRISC#23191). This commit reinstantiates it.
Signed-off-by: Andrea Caforio <[email protected]>
Co-authored-by: Martin Velay <[email protected]>
The previously reverted commit f591bea (later refined in e869152)
contained a desirable timeout implementation for the HMAC idle
polling (see #23191). This commit reinstantiates it.
Signed-off-by: Andrea Caforio <[email protected]>
Co-authored-by: Martin Velay <[email protected]>
Description
(this issue is WIP)
RV_CORE_IBEX_RND_STATUS_REG_OFFSET
.sha256/sha512
files related to OTBN.And potential improvement suggestions for SCA/FI hardening:
hardened_memcpy
) for KEY and DIGEST registers. This can also be extended to message inputs if message bits are also sensitive, depending on the use case (e.g. HMAC-DRBG).hw_started
flag.ctx
after the final call makes sense. If so, the values could be populated with random values. The suggestion is to zeroise or randomly populatectx
struct during init.hmac_en
and use it to skip key writing etc. [cryptolib, hmac] Update HMAC driver #23196 (comment)The text was updated successfully, but these errors were encountered: