FIPS Feature Improvements

[skmcgrail]

Description of changes:

• aws_lc_rs::aead::RandomizedNonceKey has been added to easily allow for encryption or decryption of data using AES-128 and AES-256 GCM with a cryptographically secure random generated 96-bit (12 byte) nonces. This provides an alternative for users who don't want to construct and manage a NonceSequence with the OpeningKey / SealingKey based types.
• aws_lc_rs::aead::TlsRecordOpeningKey and aws_lcs_rs::aead::TlsRecordSealingKey have been added to aid systems developers who are creating TLS protocol implementations. The TlsRecordSealingKey validates that the provided sequence of nonces are monotonically increasing.
• aws_lc_rs::tls_prf module has been added for systems developers who need access to TLS 1.2 PRF APIs for usage in implementing RFC 5246 and RFC 7627.
• aws_lc_rs::signature::Ed25519KeyPair::generate_pkcs8 and aws_lc_rs::signature::Ed25519KeyPair::generate_pkcs8v1 no longer use the provided &dyn SecureRandom. This is consistent with other public APIs in aws_lc_rs that don't honor this parameter. This has been treated a legacy argument that is only present in our APIs for drop-in compatibility with ring 0.16 releases.

Call-outs:

PRs that need to be merged into fips-api-changes first prior to this merging:

• Documentation cleanup #243

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.

[ctz]

• aws_lc_rs::aead::TlsRecordOpeningKey and aws_lcs_rs::aead::TlsRecordSealingKey have been added to aid systems developers who are creating TLS protocol implementations. These types validate that the provided sequence of nonces are monotonically increasing.

Unless I've missed something, I think TlsRecordOpeningKey doesn't do that[1]? And also, I don't think it should. If the nonce is reused on decryption, that is because either a) the nonce is correct, and was reused by the encrypter (so the security failure already happened, and nothing can save us), or the nonce is incorrect and the decryption won't work anyway.

[1]: ref aws-lc-fips-sys/aws-lc/crypto/fipsmodule/cipher/e_aes.c where EVP_aead_aes_128_gcm_tls13 uses plain aead_aes_gcm_open_gather in the open_gather slot, and doesn't specialise it for nonce checking.

[ctz]

(btw, if the intention is to validate the nonces in TlsRecordOpeningKey methods, they should take &mut self to avoid races from multiple calls.)

[skmcgrail]

You are correct that TlsRecordOpeningKey key doesn't enforce this behavior, and that is expected. Which is why we modeled it as not taking a &mut self reference.