One common solution to that problem is to include the public key in the data array holding the private key. The SNTRUP761 implementations I've worked with does that by default, and I thought it was a fairly common design pattern.
/Simon Falko Strenzke <falko.stren...@mtg.de> writes: > There is another point to consider for the design of a generic KEM API: the > use of the public in the > key derivation, which makes it necessary to pass the public key to the > decapsulation function if one > doesn't want to run the computation of the public key from the private key in > the decapsulation > function. > > We are using using this now for instance in our OpenPGP PQC draft > (https://github.com/openpgp-pqc/draft-openpgp-pqc/pull/66 corrects the > ECC-KEM function > signature regarding that matter). > > - Falko > > Am 24.10.23 um 08:25 schrieb NIIBE Yutaka: > > Werner Koch <w...@gnupg.org> wrote: > > On Thu, 19 Oct 2023 16:37, NIIBE Yutaka said: > > gcry_error_t gcry_kem_decap (int algo, > const void *seckey, > const void *ciphertext, > void *shared_secret); > > > I still don't feel comfortable without a size argument. > > > Assumption here (for lower level API) is: > > It's caller side (user of libgcrypt) which does static > compile-time check against ALGO and the length of each > byte-array. > > If not static, caller side can do run-time check, if needed, > before the call. > > Having a size argument would mean, > > libgcrypt does run-time check of the length (for each call) > > I wonder if this kind of run-time check in libgcrypt is useful in lower > level API. > > I could imagine having an API offering static compile-time check. In > this case, it would provide a macro something like gcry_kem_decap_check > which has length arguments. The ABI is gcry_kem_decap.
signature.asc
Description: PGP signature
_______________________________________________ Gcrypt-devel mailing list Gcrypt-devel@gnupg.org https://lists.gnupg.org/mailman/listinfo/gcrypt-devel
