Why lc_dilithium_keypair_from_seed_c rather than ML-DSA.KeyGen_internal ?

[sebastien-riou]

As this lib has been validated by CAVP, I expected to find this function but I found lc_dilithium_keypair_from_seed_c and lc_dilithium_keypair_impl instead.

As far as I can see lc_dilithium_keypair_from_seed_c is not equivalent as it introduces a DRBG instance, something which is not done in ML-DSA.KeyGen_internal.

So you have 2 functions for generating keys including one taking a seed as argument but for some reason it does not match the description of ML-DSA.KeyGen_internal.

If this is the correct understanding, then I have some questions:

• Is this for 'historical reasons' or is it intentional ?
• Do you agree that ideally the lib would include ML-DSA.KeyGen_internal ?
  • If not, why ?
  • If yes, do you have any plan to include it ?

[smuellerDD]

Am Mittwoch, 19. November 2025, 09:25:38 Mitteleuropäische Normalzeit schrieb sebastien-riou: Hi sebastien-riou,

As this lib has been validated by CAVP, I expected to find this function but I found `lc_dilithium_keypair_from_seed_c` and `lc_dilithium_keypair_impl` instead. As far as I can see `lc_dilithium_keypair_from_seed_c` is not equivalent as it introduces a DRBG instance, something which is not done in ML-DSA.KeyGen_internal.

It is NOT allowed as per FIPS 204 that ML-DSA*.internal functions are externally accessible. Only specific bypasses to parameters the external functions process are allowed. All other input sanity checks must still be performed when invoking these bypass APIs.

So you have 2 functions for generating keys including one taking a seed as argument but for some reason it does not match the description of `ML-DSA.KeyGen_internal`. If this is the correct understanding, then I have some questions: - Is this for 'historical reasons' or is it intentional ?

This is perfectly intentional as the internal function are not allowed to be used externally.

- Do you agree that ideally the lib would include `ML-DSA.KeyGen_internal` ?

I do not agree. For example, Algorithm 1 steps 2 and 3 must still be performed and thus the internal function cannot be invoked directly. The same consideration applies to the siggen/sigver aspects.

- If not, why ?

See before

- If yes, do you have any plan to include it ?

I think it is clear that there is no plan to support externalizing the internal functions. PS: I plan to talk about exactly this topic at ICMC 2026 covering all PQC algos. Feel free to join :-) Ciao Stephan

[sebastien-riou]

Thanks for providing a clear rational so quickly