Crypto: SHA-256 padding incorrectly limits message length field to 32 bits

[kaabia]

Describe the bug

This issue reports a critical compliance bug in the SHA-256 implementation, specifically within the it51xxx_hash_handler():

• Standard Violation: The SHA-256 standard (FIPS 180-4) requires the total message length ($L$) in bits to be appended as a 64-bit big-endian integer during the padding process.

• Implementation Flaw: The previous implementation incorrectly calculated and wrote only the lower 32 bits of the length field (to $W[15]$), implicitly assuming the upper 32 bits ($W[14]$) were zero.

• Impact: For message lengths exceeding $2^{32}$ bits (a very long message), this bug would cause incorrect hashing results, violating standard compliance. The fix ensures both the Most Significant Bit (MSB) and Least Significant Bit (LSB) words are correctly calculated and written using a uint64_t type.

Area: Drivers, Crypto, SHA-256

Regression

• This is a regression.

Steps to reproduce

The bug is a logic error verifiable via static code analysis.

Write:

1. Examine the padding logic in the it51xxx_hash_handler() function responsible for SHA-256.

2. The original code's manipulation of the length field (writing only to $W[15]$ or implicitly relying on a zeroed $W[14]$) confirms the incorrect 32-bit length limitation, which violates the FIPS 180-4 requirement for a 64-bit length field.

3. The issue would only manifest at runtime when attempting to hash a message longer than 500 MB (which is $2^{32}$ bits).

Relevant log output

Impact

Annoyance – Minor irritation; no significant impact on usability or functionality.

Environment

• OS: Windows WSL

• Toolchain: Zephyr SDK

• Driver/Component: it51xxx_hash_handler (SHA-256 implementation

Additional Context

Additional Context: Fix Proposal is presented in the following PR: #98616