AES-XTS into FIPS

[Taffer]

Issues:

Resolves CryptoAlg-1223

Description of changes:

Moves AES-XTS into the FIPS boundary, adds a service indicator test for the AES-XTS cipher. Extends the cipher tests in the service indicator to let each cipher specify its IV, plaintext, and expected ciphertext. Extends service indicator checks into EVP_EncryptUpdate() and EVP_DecryptUpdate().

Testing:

run_tests pass in non-FIPS and FIPS builds, I look forward to seeing what CI has to say.

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

[samuel40791765]

Nit: If we add NIST KATs to service_indicator_test.cc, I think we could add them to a separate parameterized test suite. It would be cleaner to see EVPServiceIndicatorTest test upon the same kPlaintext, kAESIV, kAESkey_256, etc. IMO. But this isn't a blocker and more of a test styling nitpick on my end.

[nebeid]

Can we add a test vector with AWSLC_NOT_APPROVED as the expected result? For example, this negative test case: https://github.com/Taffer/aws-lc/blob/4e1fd6c8f10d21a374a6539b8f4d93c26b0e88ad/crypto/fipsmodule/modes/xts_test.cc#L543

[nebeid]

EVP_Cipher_verify_service_indicator() is called within EVP_Cipher(), EVP_EncryptFinal_ex() and EVP_DecryptFinal_ex(). However, in the case of XTS, the Final functions are NOP, will we check in Update whether the cipher is xts to call EVP_Cipher_verify_service_indicator? Note also that in the case of xts, update can be called only once after init, it cannot be called repeatedly; it does the whole encryption in one shot to do the cipher stealing at the end.
I don't know if all the other ciphers listed here need to call final or not, but I guess yes.

[samuel40791765]

In my opinion, I would keep the original service indicator implementation of leaving the checks within the *Final operations. *Final might be a no-op for XTS, but it was within our general service indicator usage guidance that this "*Final" step was our way of differentiating if the user had finished the "FIPS service". This general guidance goes for all the crypto functions within AWS-LC.
If we tried to add a check within EVP_Update, it would add additional complexity for us to maintain this outlier and our service indicator usage guidance would have to be updated as well.

[nebeid]

Sorry, this may have come up previously. The comment says we test

|EVP_EncryptFinal_ex| and |EVP_DecryptFinal_ex| for approval at the end.
But I don't see we're calling Init and Update to test that they won't set Approved, then call Final to test that it does set it. Is that done elsewhere?
Also, see my comment above in the case of xts particularly where update should return approved, unless we force the FIPS user to call final which would be a NOP but just to return Approved (to be tested that this is what will happen).

[samuel40791765]

Yes this test was when of the first versions of the service indicator tests, so we hadn't checked for non-approval for Init and Update. "Taffer" has added a new non-approval check for Update on Line 116, but we should add one for init as well.