Add ML-DSA (FIPS204) #480
Add ML-DSA (FIPS204) #480
Conversation
bwesterb
force-pushed
the
bas/ml-dsa
branch
4 times, most recently
from
9537079 to
5bd6e0d
Compare
bwesterb
force-pushed
the
bas/ml-dsa
branch
2 times, most recently
from
e60db3b to
47bb92a
Compare
bwesterb
force-pushed
the
bas/ml-dsa
branch
from
1fbec7a to
7970d07
Compare
bwesterb
force-pushed
the
bas/ml-dsa
branch
from
7970d07 to
16fa7b7
Compare
There was a problem hiding this comment.
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 { |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
From the Dilithium specification:
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.
| @@ -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" | |||
There was a problem hiding this comment.
In the past, we've recommend not to use dilithium alone, but used as a hybrid.
Has something changed?
There was a problem hiding this comment.
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.
Forgot to add tests. Done now. Should be good to merge (and squash.) |
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.
|
Rebased. |
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.