Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Switch ML-DSA to use AWS-LC SHA3 #2001

Merged
merged 12 commits into from
Dec 10, 2024
Merged

Switch ML-DSA to use AWS-LC SHA3 #2001

merged 12 commits into from
Dec 10, 2024

Conversation

jakemas
Copy link
Contributor

@jakemas jakemas commented Nov 19, 2024

Issues:

Resolves CryptoAlg-2726

Description of changes:

Following the inclusion of SHAKE as an extensible-output-function (XOF) in #1839, we are now able to fully support ML-DSA with SHA3/SHAKE usage within crypto/fipsmodule. As such, all references to the internal implementation of SHA3 (within crypto/dilithium/pqcrystals_dilithium_ref_common/fips202.{h|c}) have been removed.

Call-outs:

  • The structure keccak_state provided by the Dilithium reference implementation has been replaced with KECCAK1600_CTX
  • The calls to absorb/update/final have been replaced with a straight swap to AWS-LC's implementation
  • The dilithium specific function dilithium_shake128_stream_init, dilithium_shake128_squeeze, dilithium_shake256_stream_init, dilithium_shake256_squeeze of fips202.c has been replaced with versions that call SHA3 from fipsmodule.

Testing:

The testing framework is the KATs for ML-DSA, and all other ML-DSA tests completed.

#CryptoAlg-2589 design documentation provides an analysis of all fips202.c usage from ML-DSA, to verify that all functionality that used to be provided by fips202.c has been replaced by this commit, the file has been removed from the library.

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.

@jakemas jakemas requested a review from a team as a code owner November 19, 2024 19:25
@jakemas
Copy link
Contributor Author

jakemas commented Nov 19, 2024

See c4a0fdb for the changes proposed in this PR without the muddiness of #1999

@codecov-commenter
Copy link

codecov-commenter commented Nov 19, 2024

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 78.66%. Comparing base (d681431) to head (35ae687).

Additional details and impacted files
@@            Coverage Diff             @@
##             main    #2001      +/-   ##
==========================================
- Coverage   78.68%   78.66%   -0.02%     
==========================================
  Files         598      598              
  Lines      103350   103351       +1     
  Branches    14692    14691       -1     
==========================================
- Hits        81321    81305      -16     
- Misses      21377    21393      +16     
- Partials      652      653       +1     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

Copy link
Contributor

@geedo0 geedo0 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks pretty straightforward. The only big thing missing here seems to be updates to the README.md file.


void dilithium_shake128_stream_init(keccak_state *state, const uint8_t seed[SEEDBYTES], uint16_t nonce)
/*************************************************
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll defer to the LC team on this point, but IMO the docstrings here should be in the header file and match LC's style conventions for comments. I can see that these were ported over from the fips202 source, so I can see the merit in retaining that style and content. It's also not part of LC's public interface so I feel less strong about belaboring it.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good call out. As I added these functions within the crypto/dilithium/pqcrystals_dilithium_ref_common/ directory, I wanted to be consistant with function conventions. I did the same within ML-KEM (see example).

shake128_finalize(state);
SHAKE_Init(ctx, SHAKE128_BLOCKSIZE);
SHA3_Update(ctx, seed, SEEDBYTES);
SHA3_Update(ctx, t, 2);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Perhaps extract the 2 as a constant value to improve readability?

@jakemas
Copy link
Contributor Author

jakemas commented Nov 23, 2024

Looks pretty straightforward. The only big thing missing here seems to be updates to the README.md file.

README.md updated (was waiting on merge).

geedo0
geedo0 previously approved these changes Nov 25, 2024
shake256_squeezeblocks(buf, 1, &state);
SHAKE_Init(&state, SHAKE256_BLOCKSIZE);
SHA3_Update(&state, seed, params->c_tilde_bytes);
dilithium_shake256_squeeze(&state, buf, 1);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why can't we just use SHA_Final directly?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

actually, why can't we use SHAKE256 instead of the sequence of Init, Update, Final?

Copy link
Contributor Author

@jakemas jakemas Dec 4, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Because we need an additional squeeze down at line 524 below (part of the rejection sampling loop). If we call SHAKE256 directly at this stage, we cannot additionally squeeze output later. This is exactly the difference between calling SHAKE256 as a single shot output, vs as an extensible output function, as required for both ML-KEM and ML-DSA.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

However, I agree that we can use SHA_Final directly, and have modified the PR to do this for both SHAKE256 and SHAKE 128 in f4cc0fe

@jakemas
Copy link
Contributor Author

jakemas commented Dec 6, 2024

Any further required actions here?

crypto/dilithium/pqcrystals_dilithium_ref_common/poly.c Outdated Show resolved Hide resolved
SHAKE_Init(&state, SHAKE128_BLOCKSIZE);
SHA3_Update(&state, seed, SEEDBYTES);
SHA3_Update(&state, t, 2);
SHAKE_Final(buf, &state,POLY_UNIFORM_NBLOCKS * SHAKE128_BLOCKSIZE);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
SHAKE_Final(buf, &state,POLY_UNIFORM_NBLOCKS * SHAKE128_BLOCKSIZE);
SHAKE_Final(buf, &state, POLY_UNIFORM_NBLOCKS * SHAKE128_BLOCKSIZE);

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

crypto/dilithium/pqcrystals_dilithium_ref_common/poly.c Outdated Show resolved Hide resolved
crypto/dilithium/pqcrystals_dilithium_ref_common/poly.c Outdated Show resolved Hide resolved
crypto/dilithium/pqcrystals_dilithium_ref_common/poly.c Outdated Show resolved Hide resolved
@geedo0 geedo0 merged commit 0eaa0a8 into aws:main Dec 10, 2024
121 of 124 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants