readme update

aws · Jan 15, 2025 · 195779c · 195779c
1 parent 6d214b5
commit 195779c
Showing 1 changed file with 2 additions and 2 deletions.
diff --git a/crypto/ml_dsa/ml_dsa_ref/README.md b/crypto/ml_dsa/ml_dsa_ref/README.md
@@ -7,7 +7,7 @@ The source code in this folder implements ML-DSA as defined in FIPS 204 Module-L
 The source code was imported from a branch of the official repository of the Crystals-Dilithium team: https://github.com/pq-crystals/dilithium. The code was taken at [commit](https://github.com/pq-crystals/dilithium/commit/444cdcc84eb36b66fe27b3a2529ee48f6d8150c2) as of 10/29/2024. At the moment, only the reference C implementation is imported.
 
 The code was refactored in [this PR](https://github.com/aws/aws-lc/pull/1910) by parameterizing all functions that depend on values that are specific to a parameter set, i.e., that directly or indirectly depend on the value of `DILITHIUM_MODE`. To do this, in `params.h` we defined a structure that holds those ML-DSA parameters and functions
-that initialize a given structure with values corresponding to a parameter set. This structure is then passed to every function that requires it as a function argument. In addition, the following changes were made to the source code in `pqcrystals_dilithium_ref_common` directory:
+that initialize a given structure with values corresponding to a parameter set. This structure is then passed to every function that requires it as a function argument. In addition, the following changes were made to the source code in `crypto/ml_dsa/ml_dsa_ref` directory:
 
 - `randombytes.{h|c}` are deleted because we are using the randomness generation functions provided by AWS-LC.
 - `fips202.{h|c}`, `symmetric.h`, `symmetric-shake.c` are deleted as all SHA3/SHAKE functionality is provided instead by AWS-LC fipsmodule/sha rather than the reference implementation. Calls to `dilithium_shake128_stream_init` and `dilithium_shake256_stream_init` have been inlined.
@@ -18,7 +18,7 @@ that initialize a given structure with values corresponding to a parameter set.
 - `polyvec.c`: a small fix to documentation has been made on the bounds of `polyveck_reduce`.
 - Documentation has been added to `ntt.c`, `packing.c`, `poly.c`, `polyvec.c`, and `rounding.c` that outlines the algorithm specification (including algorithm number) in FIPS 204.
 - `poly.c` and `sign.c` have been modified to cleanse intermediate data as soon as it is no longer needed as defined in FIPS 204 Section 3.6.3.
-- Intermediate values are cleansed within `crypto_sign_keypair_internal`, `crypto_sign_keypair`, `crypto_sign_signature_internal`, `crypto_sign_verify_internal`, `crypto_sign_verify`, `poly_uniform_eta`, `poly_uniform_gamma1`, and `poly_challenge` as per FIPS 204 Section 3.6.3.
+- Intermediate values are cleansed within `ml_dsa_keypair_internal`, `ml_dsa_keypair`, `ml_dsa_sign`, `ml_dsa_sign_internal`, `ml_dsa_extmu_sign`, `ml_dsa_verify_internal`, `poly_uniform_eta`, `poly_uniform_gamma1`, and `poly_challenge` as per FIPS 204 Section 3.6.3.
 - `sign.c` has been modified to provide support for ML-DSA in ExternalMu mode. This is an alternative implementation of ML-DSA sign and verify that accepts `mu` as input, rather than the raw message. As `mu` can be constructed (and thus hashed) in another cryptographic module. 
 
 **Testing**