Support "pure" ML-DSA

[WillChilds-Klein]

Issue #, if available: i/ACCP-100

Description of changes:

Overview

This PR exposes ML-DSA functionality through the Signature, KeyPairGenerator, and KeyFactory JCA interfaces. The implementation closely follows our Ed25519 implementation, as both algorithms are currently used through AWS-LC's EVP_DigestSign API initialized with a NULL message digest (these newer algorithms use a fixed, non-parameterizable digest function per spec).

We also provide benchmarks for key generation, signing, and verifying.

Interoperability

This change has been written to be interoperable and forwards-compatible with other JCA provider ML-DSA implementations, such as BouncyCastle's and OpenJDK's JEP 497.

This means that ACCP callers cannot use JDK's NamedParameterSpec classes or BouncyCastle's MLDSAParameterSpec, but allows ACCP to provide ML-DSA on supported LTS JDK versions, independent of other providers. Instead of using ParameterSpec classes, callers can request a specific security level via the algorithm name passed into KeyPairGenerator.getInstance (if no level is specified, "ML-DSA-44" is the default, conforming to JEP 497):

KeyPairGenerator g = KeyPairGenerator.getInstance("ML-DSA-87");
KeyPair kp = g.generateKeyPair(); // an ML-DSA-87 key pair

g = KeyPairGenerator.getInstance("ML-DSA");
kp = g.generateKeyPair(); // an ML-DSA-44 key pair

We also update our BouncyCastle test dependency to 1.80, allowing us to pefrorm interoperability tests with BouncyCastle's ML-DSA implementation.

Limitations

As mentioned above, ACCP does not currently support ParameterSpec-based initialization on KeyPairGenerator instances. We also don't support keysize-based initialization as it is somewhat ambiguous for ML-DSA. These limitations may change in the future.

ACCP's ML-DSA keys cannot be used directly with BouncyCastle KeyFactory or Signature instances, as BouncyCastle only supports its own keys today. To use ACCP keys with BouncyCastle, callers will need to serialize them into X509EncodedKeySpec or PKCS8EncodedKeySpec instances and pass those to BouncyCastle's KeyFactory for conversion.

Finally, ACCP cannot yet deserialize ML-DSA private keys serialized by BouncyCastle. BouncyCastle currently encodes the private key's 32 byte seed upon serialization, while ACCP expects the fully expanded private key material.

Future Work

• Migrate to streaming APIs in AWS-LC (we currently buffer entire message in memory)
• Support deserializing private key seeds (e.g. from BouncyCastle) and expanding them (this will require AWS-LC supporting ibid., we're actively working on this)
• Add ML-DSA to EvpSignatureTest suite (unblocked once we can parse BouncyCastle keys per above)
• Interoperability tests with JDK 24 (once we support that version)

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

[jakemas]

Checked through EVP logic - lgtm

[geedo0]

Minor comments, but would like to get those cleaned up before a merge.

Not that I necessarily agree with the stance, but lately we've been including complete KAT suites for every new algorithm to the library.

[WillChilds-Klein]

@geedo0

lately we've been including complete KAT suites for every new algorithm to the library.

I would've included some KATs if it were straightforward. However, because ML-DSA introduces distinct randomness into each signature, signatures produced with identical parameters are unique. Since ACCP/JCA doesn't have a clean way of exposing AWS-LC's ML-DSA derandomization APIs, KATs for this PR are currently infeasible.