Introduce SHA256/SHA512 interleave testing, HAVE_DSA; revised ERROR_OUT

[gojimmypi]

Description

Note this description has been modified since originally submitted.

Background

While working on wolfSSL/wolfssh-examples#4 an error was encountered calculating the SSH signature with the SHA256 HW Acceleration enabled on the Espressif ESP32.

The root cause of the problem is the random.c has several functions such as HashGen() which may initiate their own local SHA256 hash even when SINGLE_THREADED is enabled. The current Espressif ESP32 hardware "in use" detection is currently a simple int InUse variable. This does not allow multiple, interleaved hashes to be computed separately with single-use hardware, such as that in an SSH signature and the contained hash within.

This is why the wolfSSH example was able to generate a SHA384 hardware-accelerated signature successfully.

Interleaving tests are going to be needed for future expansion of our Espressif library as newer chips actually do support interleaving in hardware.

Details

This PR adds interleaving calculations to the wolfCrypt test.c.

Code is enabled by default unless turned off with NO_WOLFSSL_SHA256_INTERLEAVE and/or NO_WOLFSSL_SHA512_INTERLEAVE

I've also added what I found was an interesting test: an exactly BLOCKSIZE long input test and a known output for SHA256 testing.

For exhaustive testing, I could not find a way to enable DSA testing, so I added HAVE_DSA to settings.h to be able to force it on.

Other minor changes such as adjusting the order of ERROR_OUT output to print an error first, then the system config, then a warning that the app has been halted. The prior steps looked nearly like the embedded app had otherwise rebooted. (the system config detail has grown fairly long). For the Espressif environment, a failed test is a bit more obvious now:

I originally had a breadcrumb macro for the ERROR_OUT, but changed it to WOLFSSL_ENTER("error_test"); (thanks @bandi13 for the excellent suggestions!)

While enabling more items for testing, there was a compile error in wolfSSL_DH_compute_key regarding a missing initialization. A fix for that is included here, too.

There was a minor problem with the SHA metrics with NO_WOLFSSL_ESP32_CRYPT_HASH, so that fix is also included.

To make am even more interesting and aggressive SHA test, I also suggest calling all of the other SHA tests during each respective test. For example: Call the SHA512 test between each init and final step of the SHA256 test.

Fixes zd# n/a

Testing

How did you test?

Tested only with Espressif hardware acceleration. This test is only moderately interesting for software calculations, but may be of high interest on other platforms with SHA256 accleration.

Checklist

• added tests
• updated/added doxygen
• updated appropriate READMEs
• Updated manual and documentation

[ejohnstown]

retest this please

[dgarske]

This NO_WOLFSSL_SHA256_INTERLEAVE macro is new and only applies to test.c correct? If so the name should include "TEST" in it. Also needs documented.
I believe the interleave avoids the copy, update, final scenario?

[gojimmypi]

This NO_WOLFSSL_SHA256_INTERLEAVE macro is new and only applies to test.c correct?

Yes it is new; No, not intended for only test.c. Although it is only included in test.c now, future versions of the Espressif library may support SHA interleaving (on SoC devices that support it). I envision this as being an optional feature. It will likely be valuable when testing performance between systems that have hardware-accelerated SHA interleaving enabled (a bit of overhead expected) vs no interleaving needed.

An example of needing the interleave is the SSH signature. Other applications may not need nor want the interleaving overhead needed for hardware interleaving.

I believe the interleave avoids the copy, update, final scenario?

Interesting question. No, not avoided. The interleave does perform the initialize, update, and final (then copy to output). The interesting thing is that when for example one SHA256 hash is in progress, what happens to a concurrent SHA256 in progress at the same time in a different object.

There's another type of copy that might be interesting to more exhaustively test as well: the copy of the wc_Sha256 object to another instance. I could address that in a separate PR (or here?) if desired.

Also needs documented.

Thanks for reminder. Added wolfSSL/documentation#120

[dgarske]

If you are adding active_wolfssl_test please expand or provide a way to eliminate for small targets.

[gojimmypi]

I've removed the active_wolfssl_test after discussing with @bandi13. Same functionality, but much better.

See revised PR description.

[gojimmypi]

Jenkins retest this please

[dgarske]

Thanks. Looks good/tests out. I like the extra "entering". Over to @douzzer