[gnutls-devel] GnuTLS | leancrypto: support leancrypto for post-quantum algorithms (!1925)

[Read-only notification of GnuTLS library development activities]

Stephan Mueller commented on a discussion on lib/nettle/pk.c: https://gitlab.com/gnutls/gnutls/-/merge_requests/1925#note_2311848476

 >  {
 > -	mpz_t p;
 >  	int ret;
 > +	enum lc_kyber_type type;
 > +	struct lc_kyber_sk sk;
 > +	struct lc_kyber_pk pk;
 > +	gnutls_datum_t tmp_raw_priv = { NULL, 0 };
 > +	gnutls_datum_t tmp_raw_pub = { NULL, 0 };
 > +	uint8_t *ptr;
 > +	size_t len;
 > +
 > +	type = ml_kem_pk_to_lc_kyber_type(algo);
 > +	if (type == LC_KYBER_UNKNOWN)
 > +		return gnutls_assert_val(GNUTLS_E_UNKNOWN_PK_ALGORITHM);
 > +
 > +	ret = lc_kyber_keypair(&pk, &sk, lc_seeded_rng, type);

For internal calls within a FIPS module, that is no problem. But if you have a module which provides an API with this capability, this is an issue. FIPS requires that any algorithm performs the DRBG-call internally if there is a need for such. Already the key-gen API with the RNG-callback parameter took a long discussion to allow it (leancrypto offers it to perform a transparent key derivation - e.g. an SP800-108 KDF can be easily wrapped as an RNG-provider and thus you can deterministically derive, say, an ML-KEM key from some other data by furnishing a KDF-"RNG" instead of lc_seeded_rng). But this argument does not work with the shared secret key gen. Thus, the FIPS-folks want to have an ML-KEM API that does not offer the means to provide the DRBG reference.

As I said, in previous instances of the API, the caller was able to provide the RNG provider to the ML-KEM enc API.

-- 
Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1925#note_2311848476
You're receiving this email because of your account on gitlab.com.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnutls-devel/attachments/20250123/fb09e56b/attachment-0001.html>