Implementation of PQC Algorithms in libgcrypt

[Simon Josefsson]

Hi

I noticed this thread just after submitting sntrup761 [1] patches.

My opinion is that libgcrypt's public-key API is a bad fit for KEM's: it
uses S-expressions and MPI data types.  I believe the crypto world
rightly has moved away from those abstraction, towards byte-oriented
designs instead, for simplicity and safety.  Compare gcry_ecc_mul_point
for X25519 and gcry_kdf_derive for KDF's.  Could you implement Kyber as
a KEM using the API that I suggested?  I think that would be
significantly simpler, and would help validate the KEM API as supporting
more than one KEM.  I would strongly support having a KEM API that is
not using sexp/mpi, but I wouldn't object to a sexp/mpi API in addition
to it, for different use-cases.

/Simon

[1] https://gitlab.com/jas/libgcrypt/-/commits/jas/sntrup761

Falko Strenzke <falko.strenzke at mtg.de> writes:

> Hi Werner,
>
> the only API change is the addition of the following interface function:
>
> gcry_err_code_t
> _gcry_pk_encap(gcry_sexp_t *r_ciph, gcry_sexp_t* r_shared_key, gcry_sexp_t s_pkey)
>
> This also means that the public key spec needs to contain this additional function. For Kyber our public key spec currently looks as follows:
>
> gcry_pk_spec_t _gcry_pubkey_spec_kyber = {
>   GCRY_PK_KYBER, {0, 1},
>   (GCRY_PK_USAGE_ENCAP),        // TODOMTG: can the key usage "encryption" remain or do we need new KU "encap"?
>   "Kyber", kyber_names,
>   "p", "s", "a", "", "p",       // elements of pub-key, sec-key, ciphertext, signature, key-grip
>   kyber_generate,
>   kyber_check_secret_key,
>   NULL,                         // encrypt
>   kyber_encap,
>   kyber_decrypt,
>   NULL,                         // sign,
>   NULL,                         // verify,
>   kyber_get_nbits,
>   run_selftests,
>   compute_keygrip
> };
>
> For the PKEs the encapsulation function would of course be NULL. Regarding the TODO on the key usage marked in the code above, this so far
> doesn't seem to have any implications for us so the decision isn't urgent from my point of view.
>
> - Falko    
>
> Am 30.03.23 um 15:43 schrieb Werner Koch:
>
>  On Wed, 29 Mar 2023 10:09, Falko Strenzke said:
>
>  While the integration of the signature algorithms is straightforward, the KEM
> requires a new interface function, as the KEM encapsulation cannot be modelled
> by a public-key encryption.
>
>
> It would be good if we can discuss a proposed API early enough, so that
> we can see how it fits into the design of Libgcrypt.  Can you already
> roughly describes the needs?
>
>
> Salam-Shalom,
>
>    Werner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 255 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gcrypt-devel/attachments/20230515/b0a33af9/attachment.sig>