[PATCH] Add Streamlined NTRU Prime sntrup761.

[Falko Strenzke]

Hi Simon,

Am 16.05.23 um 08:56 schrieb Simon Josefsson via Gcrypt-devel:
> Hi
>
> Attached is a second version of the sntrup761 patch, this time using a
> minimal API that would work for Kyber too (please confirm).  Unless we
> know complexity is required, I prefer to keep things minimal.
>
> I've pushed it to:
> https://gitlab.com/jas/libgcrypt/-/commits/jas/sntrup761v2
>
> Below is the added API.  Thoughts?
>
> enum gcry_kem_algos
>    {
>      GCRY_KEM_SNTRUP761 = 761,
>    };
>
> #define GCRY_KEM_SNTRUP761_SECRETKEY_SIZE 1763
> #define GCRY_KEM_SNTRUP761_PUBLICKEY_SIZE 1158
> #define GCRY_KEM_SNTRUP761_CIPHERTEXT_SIZE 1039
> #define GCRY_KEM_SNTRUP761_SHAREDSECRET_SIZE 32
>
> gcry_error_t gcry_kem_keypair (int algo,
> 			       void *pubkey,
> 			       void *seckey);
>
> gcry_error_t gcry_kem_enc (int algo,
> 			   const void *pubkey,
> 			   void *ciphertext,
> 			   void *ss);
>
> gcry_error_t gcry_kem_dec (int algo,
> 			   const void *ciphertext,
> 			   const void *seckey,
> 			   void *ss);

I think this is already going into the right direction. However, I have 
some proposals:

1. I would prefer a more type safe API: distinct public and private key 
objects instead of void pointers, i.e gcry_kem_public_key_t and 
gcry_kem_private_key_t. From your proposed API it does not become clear 
if pubkey and seckey are objects or just byte arrays. Since 
instantiating a key from a byte array may involve some precomputations 
(imagine for instance instantiating a private key from a PRNG seed), for 
efficiency reasons it is in my view necessary to have public and private 
key objects.

2. Also the enum should by typedef'd and used with its type in the 
function signature.

3. There is no need to provide algo again in the enc/dec functions. A 
key object will know it's algorithm. (Probably this is due to key void 
pointers meant as byte arrays)

4. All input/output byte arrays should be typed as uint8_t* and be 
passed in with their lengths. If without lengths, client code will be 
prone to memory access errors.

5. Then we will also need extra functions for serialization and 
deserialization of keys.

- Falko

>
> /Simon
>
> _______________________________________________
> Gcrypt-devel mailing list
> Gcrypt-devel at gnupg.org
> https://lists.gnupg.org/mailman/listinfo/gcrypt-devel
-- 

*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/20230516/cc4ff2fa/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bl8h4Ks4fuYl1XEo.png
Type: image/png
Size: 5256 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gcrypt-devel/attachments/20230516/cc4ff2fa/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: xsNU0Yk5v78SRIzb.png
Type: image/png
Size: 4906 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gcrypt-devel/attachments/20230516/cc4ff2fa/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/20230516/cc4ff2fa/attachment-0001.bin>