The Hmac SHA512 libgcrypt authenticate call breaks libgcrypt state at the gcry_mac_read function

[IbraheemYSaleh]

The Hmac SHA512 libgcrypt authenticate call breaks libgcrypt state at the gcry_mac_read function... I don't know why.

I've commented out the tests as part of my https://github.jpl.nasa.gov/ASEC/AMMOS-CryptoLib/issues/52 implementation (they were silently broken before due to another bug that is fixed with that PR).

See the relevant code here:
https://github.com/nasa/CryptoLib/pull/99/files#diff-8455637f5a51288fb98808edae34ef7ba4faf362e80d728810678ec2701f1399R655

https://github.com/nasa/CryptoLib/pull/99/files#diff-8455637f5a51288fb98808edae34ef7ba4faf362e80d728810678ec2701f1399R769

Commented out all HMAC SHA 512 tests:
https://github.com/nasa/CryptoLib/pull/99/files#diff-8e1101bbd09e2bc44055d6ad4f916e9c4f37dc4d22df1c4ab979a112508c11edR2289

[IbraheemYSaleh]

Note: This issue becomes apparent when running any decrypt tests after an HMAC SHA 512 Encrypt test has been run.

[dccutrig]

Tests NIST_DEC_HMAC_VALIDATION.SHA_512_PT_128_TEST_0 & NIST_DEC_HMAC_VALIDATION.SHA_512_PT_128_TEST_1 are failing when the entire test suite is ran (et_dt_validation). Appears specifically to occur after either encryption test SHA_512_PT_128_TEST_2 or SHA_512_PT_128_TEST_3 are ran... note that these tests run fine individually.

[dccutrig]

This is atleast partially related to test setup - researching which key lengths SHA512 should support and how it should do so. Found some configurations in the test related to key length which caused the other tests to fail as the SADB is not reset between between test runs.