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

Add ML-DSA (FIPS204) #480

Merged
merged 11 commits into from
Oct 9, 2024
Merged

Add ML-DSA (FIPS204) #480

merged 11 commits into from
Oct 9, 2024

Conversation

bwesterb
Copy link
Member

@bwesterb bwesterb commented Feb 15, 2024

Note There are no complete test vectors for FIPS 204 yet. I propose we'll wait for that before we merge this. (The ACVP test vectors only test ML-DSA.Sign_internal.)

Adds ML-DSA aka FIPS 204.

Tests against reference implementation and ACVP test vectors.

Keeps old Dilithium around in case it's used, but removes the AES modes.

Hooks Dilithium and ML-DSA into the generic signatures API. Removes the old Dilithium mode API.

Adds support for the ML-DSA randomised variant, but only via the package API — not generic signature API.

Does not add support for the HashML-DSA variants.

@bwesterb bwesterb force-pushed the bas/ml-dsa branch 4 times, most recently from 9537079 to 5bd6e0d Compare February 15, 2024 13:06
@bwesterb bwesterb changed the title [WIP] Add ML-DSA (FIPS204) [DNM] Add ML-DSA (FIPS204) Feb 15, 2024
@bwesterb bwesterb marked this pull request as draft February 15, 2024 13:08
@bwesterb bwesterb force-pushed the bas/ml-dsa branch 2 times, most recently from e60db3b to 47bb92a Compare February 15, 2024 13:14
@bwesterb bwesterb requested a review from armfazh February 15, 2024 13:22
sign/dilithium/mldsa65.go Outdated Show resolved Hide resolved
@bwesterb bwesterb changed the title [DNM] Add ML-DSA (FIPS204) Add ML-DSA (FIPS204) Aug 20, 2024
@bwesterb bwesterb marked this pull request as ready for review August 20, 2024 13:42
@bwesterb bwesterb removed the on-hold label Aug 20, 2024
@bwesterb bwesterb self-assigned this Aug 20, 2024
@bwesterb bwesterb removed the on-hold label Sep 25, 2024
Copy link
Contributor

@armfazh armfazh left a comment

Choose a reason for hiding this comment

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

Just minor changes. Overall is ok.

Q: is this compliant with ACVP test files?

https://github.com/usnistgov/ACVP-Server/tree/master/gen-val/json-files/ML-DSA-sigGen-FIPS204

SignTo(sk, msg, sig[:])
return sig[:], nil
{{- if .NIST }}
if err = SignTo(sk, msg, nil, false, ret[:]); err != nil {
Copy link
Contributor

Choose a reason for hiding this comment

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

here we are defaulting Sign to be a deterministic algorithm,
From Sec 3.4:

Only implementing the hedged variant (i.e., without the deterministic variant) is sufficient to guarantee interoperability.

It seems to me that the default should be randomized signatures.
Note that Sign receives a 'rand io.Reader' variable for providing randomness to the function.

Copy link
Member Author

@bwesterb bwesterb Oct 8, 2024

Choose a reason for hiding this comment

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

From the Dilithium specification:

Screenshot 2024-10-08 at 12 45 39

Randomised signing is easier to make side channel secure against power/EM leakage in hardware. Thus it makes sense to use it as default in hardware. In software deterministic signing as default seems to make more sense. I don't think it makes a big difference. A non security argument is that the deterministic variant is easier to test.

sign/dilithium/templates/pkg.templ.go Show resolved Hide resolved
sign/internal/dilithium/aes.go Outdated Show resolved Hide resolved
sign/dilithium/dilithium.go Show resolved Hide resolved
sign/dilithium/mode3/internal/dilithium.go Show resolved Hide resolved
sign/schemes/schemes.go Outdated Show resolved Hide resolved
@@ -16,13 +16,27 @@ import (
"github.com/cloudflare/circl/sign/ed448"
"github.com/cloudflare/circl/sign/eddilithium2"
"github.com/cloudflare/circl/sign/eddilithium3"

dilithium2 "github.com/cloudflare/circl/sign/dilithium/mode2"
Copy link
Contributor

Choose a reason for hiding this comment

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

In the past, we've recommend not to use dilithium alone, but used as a hybrid.
Has something changed?

Copy link
Member Author

Choose a reason for hiding this comment

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

For the web, PQ certificates only add value once a CRQC is close. Once that happens, hybrids don't make sense anymore. Also, the standardisation of hybrids for signatures is quite messy.

@bwesterb
Copy link
Member Author

bwesterb commented Oct 8, 2024

Q: is this compliant with ACVP test files?

Forgot to add tests. Done now. Should be good to merge (and squash.)

bwesterb and others added 5 commits October 8, 2024 18:15
The final version of FIPS204 has not been released, thus this
implementation is not yet final.
Remove old mode API and hook Dilithium and ML-DSA into generic
signature API.

Expose support for randomized ML-DSA mode. (It is not exposed
in the generic signature API.)

Remove old AES variants of Dilithium.

Does not add the HashML-DSA variants (yet).
Fix one bug in key derivation.
@bwesterb
Copy link
Member Author

bwesterb commented Oct 8, 2024

Rebased.

@armfazh armfazh merged commit e2bbd01 into main Oct 9, 2024
10 checks passed
@armfazh armfazh deleted the bas/ml-dsa branch October 9, 2024 03:07
@armfazh armfazh mentioned this pull request Oct 9, 2024
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.

3 participants