Why does the sha2_routines.c: sw_sha256_process function use ATCA_UINT32_HOST_TO_LE by default?

[xingyi-engine]

Describe the bug
A clear and concise description of what the bug is.

When I ported CryptoLib to the STM32 platform, I encountered an issue where using the atcab_ecdh_ioenc function resulted in an incorrect premaster key every time. Upon investigation, I discovered that the sw_sha256_process function in sha2_routines.c was using ATCA_UINT32_HOST_TO_LE by default for byte order conversion. Changing this to ATCA_UINT32_HOST_TO_BE resolved the problem and produced the correct result. According to the SHA-256 standard specified in RFC 4634, data should be interpreted using big-endian byte order by default.

To Reproduce
Steps to reproduce the behavior:

1. Go to '...'
2. Click on '....'
3. Scroll down to '....'
4. See error

Expected behavior
A clear and concise description of what you expected to happen.

Additional context
Add any other context about the problem here.

[Srinivas-E]

Hi @xingyi-engine
As sw_crypto is executed in the host environment/MCU where the library resides, our tests on a Windows host platform could not reproduce such issue. We shall look into this and take it for further actions.
Thank you for bringing this note and we shall keep you posted.

[AriyaKrishnanAK]

Hi @xingyi-engine,

Thank you for your detailed feedback regarding the behavior you observed when porting CryptoLib to the STM32 platform.

Upon reproducing the environment using QEMU for a big-endian system and porting the library accordingly, we were able to confirm that the SHA-2 implementation (sw_sha256_process) behaves correctly according to the specification when properly handling byte order.

In addition, for SHA processing, the message block is explicitly byte-swapped during loading. This ensures that the word values (w_union.w_dword) are always in big-endian format, regardless of the system's native endianness (little or big endian).
Thus, the SW implementation properly handles both little-endian and big-endian architectures consistently.

Please let me know in case you need any further assistance.

Regards,
Ariya

[Srinivas-E]

Hi @xingyi-engine,

Thank you for your detailed feedback regarding the behavior you observed when porting CryptoLib to the STM32 platform.

Upon reproducing the environment using QEMU for a big-endian system and porting the library accordingly, we were able to confirm that the SHA-2 implementation (sw_sha256_process) behaves correctly according to the specification when properly handling byte order.

In addition, for SHA processing, the message block is explicitly byte-swapped during loading. This ensures that the word values (w_union.w_dword) are always in big-endian format, regardless of the system's native endianness (little or big endian). Thus, the SW implementation properly handles both little-endian and big-endian architectures consistently.

Please let me know in case you need any further assistance.

Regards, Ariya

Hi @xingyi-engine ,
Just checking if you have any feedback on our latest update, before resolving this task.
Pld do re-open or log a new one if you have any open items.

[xingyi-engine]

Hi @xingyi-engine,
Thank you for your detailed feedback regarding the behavior you observed when porting CryptoLib to the STM32 platform.
Upon reproducing the environment using QEMU for a big-endian system and porting the library accordingly, we were able to confirm that the SHA-2 implementation (sw_sha256_process) behaves correctly according to the specification when properly handling byte order.
In addition, for SHA processing, the message block is explicitly byte-swapped during loading. This ensures that the word values (w_union.w_dword) are always in big-endian format, regardless of the system's native endianness (little or big endian). Thus, the SW implementation properly handles both little-endian and big-endian architectures consistently.
Please let me know in case you need any further assistance.
Regards, Ariya

Hi @xingyi-engine , Just checking if you have any feedback on our latest update, before resolving this task. Pld do re-open or log a new one if you have any open items.

Function: atcab_ecdh_ioenc
Platform: STM32

Issue:
When calling the atcab_ecdh_ioenc function on the STM32 platform, the output did not match the expected result.

Investigation & Findings:

This function internally utilizes atcac_sw_sha2_256 for SHA-256 calculations.

Key Observation: Replacing the calls to atcac_sw_sha2_256 with the equivalent mbedtls_sha256 function from the mbedTLS library produced the correct result.

Suspicion: This strongly suggested a potential issue within the atcac_sw_sha2_256 implementation.

Root Cause Identified: Upon inspecting the atcac_sw_sha2_256 algorithm, it was discovered that changing the byte order macro ATCA_UINT32_HOST_TO_LE to ATCA_UINT32_HOST_TO_BE resolved the issue and yielded the correct result.

Question:
Given this fix, I am uncertain whether specific macro definitions related to the SHA-256 algorithm implementation need to be explicitly enabled (or if the byte order assumption in the original code was incorrect).

[github-actions]

This issue has been marked as stale - please confirm the issue still exists with the latest version of the library and update the issue if it remains