Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Missing SHA2 test #5989

Closed
gojimmypi opened this issue Jan 19, 2023 · 2 comments
Closed

Missing SHA2 test #5989

gojimmypi opened this issue Jan 19, 2023 · 2 comments
Assignees

Comments

@gojimmypi
Copy link
Contributor

gojimmypi commented Jan 19, 2023

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:

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.

@gojimmypi
Copy link
Contributor Author

I've added new SHA-512/224 and SHA-512/256 tests in #6097.

There should probably be the companion hmac_sha512_224_test() and hmac_sha512_256_test() in the test.c HMAC section added as well.

@gojimmypi
Copy link
Contributor Author

I believe this was addressed in #7262 and #7505

There could be additional tests. I've added this to the mothball section of #6234, just in case.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant