Implementation of PQC Algorithms in libgcrypt
Falko Strenzke
falko.strenzke at mtg.de
Mon May 15 17:07:15 CEST 2023
Hi Simon,
indeed, there is considerable overhead in our implementation of the
S-Expressions interface for the extraction of values and MPI <-> byte
array conversions even though each Kyber "token" is merely an opaque
byte array. However, we don't consider it our call to divert from the
existing API as we can't gauge the implication of that for the client
code, e.g. GnuPG. So we basically consider this the maintainer's decision.
I looked through your API. It is indeed much simpler. I have the
following points, however:
1. I don't fully understand the design logic regarding the
gcry_kem_hd_t. I understand that it makes sense to use it for the
encryption and decryption to instantiate a particular key. But for the
key generation I don't per se see why it needs a handle. Is it required
for precomputations in the case of NTRU Prime? (or anticipated that this
is the case for other KEMs?)
2. "open" / "close" are in my opinion not the best names for the
function to create and destroy such a handle. These terms rather suggest
the handling of a file or a pipe. I know these terms are also used in
the hash API, but I think more appropriate names would "create" /
"destroy" or something similar. Maybe it makes sense to make the move to
a new terminology here.
3. While the previous two points are rather minor or even cosmetic, this
one is really important in my opinion: we need an API that allows for
derandomized key generation and encapsulation to support KAT tests for
all operations. The Kyber reference implementation already supports such
KAT tests. I would anyway have raised the question here how to realize
that. Signature functions in libgcrypt already support a
"random-override" parameter, but so far I don't really understand how it
works and whether it would be suitable to use it for the KEM API as
well. Ideally, I think, the new API would allow to provide an RNG object
and to set it to a specific seed before any operation (possibly via the
KEM handle). However, it would probably be better if this functionality
is only supported by an internal test-API and not available to normal
clients. But I am not sure how to realize that in the current design of
libgcrypt.
- Falko
Am 15.05.23 um 16:20 schrieb 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
--
*MTG AG*
Dr. Falko Strenzke
Executive System Architect
Phone: +49 6151 8000 24
E-Mail: falko.strenzke at mtg.de
Web: mtg.de <https://www.mtg.de>
*MTG Exhibitions – See you in 2023*
------------------------------------------------------------------------
<https://community.e-world-essen.com/institutions/allExhibitors?query=true&keywords=mtg>
<https://www.itsa365.de/de-de/companies/m/mtg-ag>
MTG AG - Dolivostr. 11 - 64293 Darmstadt, Germany
Commercial register: HRB 8901
Register Court: Amtsgericht Darmstadt
Management Board: Jürgen Ruf (CEO), Tamer Kemeröz
Chairman of the Supervisory Board: Dr. Thomas Milde
This email may contain confidential and/or privileged information. If
you are not the correct recipient or have received this email in error,
please inform the sender immediately and delete this email. Unauthorised
copying or distribution of this email is not permitted.
Data protection information: Privacy policy
<https://www.mtg.de/en/privacy-policy>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gcrypt-devel/attachments/20230515/55a247dd/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Y0kNcAEqvMyKELQS.png
Type: image/png
Size: 5256 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gcrypt-devel/attachments/20230515/55a247dd/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: eTvco00Nz4KhPB6y.png
Type: image/png
Size: 4906 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gcrypt-devel/attachments/20230515/55a247dd/attachment-0003.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4764 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://lists.gnupg.org/pipermail/gcrypt-devel/attachments/20230515/55a247dd/attachment-0001.bin>
More information about the Gcrypt-devel
mailing list