Kyber (ML-KEM) is in libgcrypt 1.11.
I think that we can take same approach of Kyber for Dilithium (ML-DSA); Including upstream code as intact as possible (so that auditing the code can be easier), provides three variants (of 2, 3, and 5) in a way of good performance.
| Status | Assigned | Task | ||
|---|---|---|---|---|
| Open | None | T6636 PQC Implementation | ||
| Open | • gniibe | T6637 PQC for Libgcrypt | ||
| Open | • gniibe | T7640 ML-DSA for libgcrypt |
Looking the FIPS 204 document, using the following functions (API) is good:
int crypto_sign_keypair_internal(uint8_t *pk, uint8_t *sk,
uint8_t seed[SEEDBYTES]);
int crypto_sign_signature_internal(uint8_t *sig,
size_t *siglen,
const uint8_t *m,
size_t mlen,
const uint8_t *pre,
size_t prelen,
const uint8_t rnd[RNDBYTES],
const uint8_t *sk);
int crypto_sign_verify_internal(const uint8_t *sig,
size_t siglen,
const uint8_t *m,
size_t mlen,
const uint8_t *pre,
size_t prelen,
const uint8_t *pk);That is, we won't have the randombytes function, but use these internal API within libgcrypt, so that KAT tests can be cleanly implemented.
To support Dilithium, we need to extend data handling of libgcrypt.
I propose following changes:
The commit rC23543b6c1497: Add mldsa_compute_keygrip and let private-key include "p". works well for me.
Reading https://openssl-library.org/files/blog/Request_to_Extend_IETF_WGLC_for_PQ_Key_Specifications.pdf ,
seed (with "S") is included in the private-key.