Expose SHAKE through the EVP API

[WillChilds-Klein]

Issues

Resolves CryptoAlg-2034

Notes

This commit exposes our extant SHAKE implementation through the EVP digest API and incorporates that implementation into the FIPS service indicator and ACVP tooling. SHAKE differs from traditional digest functions in that it does not have a fixed output digest size. When using the incremental EVP API, the output size is specified on finalization through EVP_DigestFinalXOF. This additional parameter percolates throughout the EVP and test code, as the function signature of EVP_DigestFinalXOF is different from that of EVP_DigestFinal or EVP_DigestFinal_ex.

We also add SHA3 to the self tests. As noted below, while the self-tests don't include actual tests for every approved digest algorithm we support, they do cover the core implementation of every approved digest. SHA224 is covered by the SHA256 self-test; SHA384, SHA512-224, and SHA512-256 are covered by the SHA512 self-test; SHAKE-128, SHAKE-256, and all the SHA3 variants are covered by the SHA3-512 self-test.

---

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license and the ISC license.

[samuel40791765]

Only reviewed 48be6d7, but hte service indicator changes/tests lgtm 👍

[darylmartin100]

Since you are marking this as an approved algorithm, do we need to add a corresponding self test in self_check.c?

[WillChilds-Klein]

Since you are marking this as an approved algorithm, do we need to add a corresponding self test in self_check.c?

@darylmartin100 --That's a good question. Right now, we're missing coverage in self_check.c for the following approved hash algorithms:

• SHA2: SHA224, SHA384, SHA512-224, SHA512-256
• SHA3: SHA3-224, SHA3-256, SHA3-384, SHA3-512
• SHAKE: SHAKE-128, SHAKE-256

I'm not sure what the decision criterion is for adding an algorithm to self_check.c, but it seems like if we add SHAKE, we should add the other missing ones as well.

[dkostic]

one general question: can the finalXOF function be called more than once on the same context object and what's the expected behavior in that case?

[WillChilds-Klein]

one general question: can the finalXOF function be called more than once on the same context object and what's the expected behavior in that case?

@dkostic -- I don't think we should allow that (neither does OpenSSL). For regular digests, we technically allow multiple calls to EVP_DigestFinal_ex, but advise against it in our documentation. EVP_DigestFinal cleans up the ctx, so it can't be called again without re-initialization.

I've added a test case to digest_test.cc to assert this behavior.