Missing SHA2 test #5989
Description
Version
latest master
Description
As first noticed in #5948 the EDD25519 wolfcrypt test is failing on the ESP32 when the Stack Smashing was set to none. This is of course counter intuitive to have the test be successful when Stack Smashing is turned on at set to normal. As the protective modes are typically left on during development, this problem went undetected for many months as the tests were otherwise all successful with the ESP-IDF Stack Smashing set to Normal.
The root cause has been isolated to changes in 8bb6ff8 from #5326 to one or more of these files:
- wolfcrypt\src\sha512.c
- wolfcrypt\src\sha256.c
- wolfcrypt\src\sha.c
- wolfssl\wolfcrypt\src\port\Espressif\esp32_sha.c
The breaking changes are specific to only the HW cryptographic acceleration features being turned ON for the ESP32. The problem is not observed for wolfSSL software algorithms.
Although specific to only HW acceleration on the ESP32, there's still something that can pass the SHA2 tests, yet still be problematic.
Thus if there's a problem in the SHA2 code that's detected in the EDD25519 test but not the SHA tests, then an as-yet-to-be-determined specific SHA test would appear to be missing from the SHA2 test suite.
Edit: One of the potentially missing tests is the root cause of the ED25519 ESP32 failure: apparently initialized, but actually copied ctx values. One the surface, this sounds fine, until one realizes that with hardware acceleration there's single-use hardware state saved in the ctx, (e.g. WC_ESP32SHA as part of struct wc_Sha256 ). which of course cannot accurately apply to multiple concurrent ctx values after a copy.
One possible solution to the copy detection is for the ctx object to keep track of how it was initialized. The intializer keeps track of the address of the ctx object in which it was initialized. If the value does not match, the ctx is likely a copy. In this case, revert to SW as the HW state cannot be considered reliable.