Page MenuHome GnuPG

ML-DSA for libgcrypt
Open, WishlistPublic

Description

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.

Event Timeline

gniibe triaged this task as Wishlist priority.May 7 2025, 7:43 AM
gniibe created this task.

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:

  • internal flag of PUBKEY_FLAG_BYTE_STRING to ask opaque MPI for data to be signed/verified.
  • The format of data as: (data(raw)[(flags no-prefix)](value ...)[(label ...)][(random-override ...)]): message, context, and random. Optional no-prefix flag to ask specific way of signing, controlling the internal, for Known Answer Tests (siggen).