8000 Wrong absorbing bytes in the Dilithium · Issue #480 · PQClean/PQClean · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

Wrong absorbing bytes in the Dilithium #480

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.

Sign up for GitHub

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

Jump to bottom
Open
xurq5953 opened this issue Feb 23, 2023 · 3 comments
Open

Wrong absorbing bytes in the Dilithium #480

xurq5953 opened this issue Feb 23, 2023 · 3 comments

Comments

@xurq5953
Copy link

In documents of Dilithium it should absorb 32 bytes seed and 2 bytes nonce to SHAKE256 in the sampling s1 & s2. And it should absorb 48 bytes seed and nonces to SHAKE256 in the ExpandMask function. However, the implementations(Dilithium2 under AVX2) in this project absorb 64 bytes seed and 2 bytes nonce both in these two functions.
@thomwiggers
Copy link
Member

This code largely comes from upstream. Can you confirm if the issue also exists in the reference implementation at https://github.com/pq-crystals/dilithium ?

@xurq5953
Copy link
Author

This code largely comes from upstream. Can you confirm if the issue also exists in the reference implementation at https://github.com/pq-crystals/dilithium ?

Yes, this problem also exists in the reference Dilithium implementations(https://github.com/pq-crystals/dilithium). The lastest update of the reference implementation was submitted 2 years ago. But the finalist round of NIST PQC was published in 2022.
Although the implementation in the zip submitted to the NIST (https://csrc.nist.gov/Projects/post-quantum-cryptography/selected-algorithms-2022) have corrected the absorbing bytes in the ExpandMask function and sampling of s1 & s2. The XOF funciton used in the sampling of s1 & s2 in this zip is SHAKE128, which specified as SHAKE256 in the documentation.

@thomwiggers
Copy link
Member

You'd best submit this question to the upstream repository and/or the NIST pqc-forum mailing list then, I suppose. We want to remain KAT-compatible with the "reference" implementation until such a time that it is changed, and the KAT values would change if we fix this (because they are computed by a predictable RNG replacement).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@thomwiggers @xurq5953
0