[PATCH] Add Streamlined NTRU Prime sntrup761.

[Simon Josefsson]

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

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

Thank you for feedback!

> 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.

This is a trade-off, and my rationale was that I prefer doing
byte-oriented APIs since that seems to what all modern KEM's are using
(including Kyber?).  And for some reason byte-strings are passed as
'void*' in libgcrypt, so I followed that style.  There should be
documentation explaining this.

I think the core decision should be to use 1) byte-oriented API or 2)
some higher-level representation like MPI/sexp.  The API types follow
from that decision.  I agree with you that 'void*' is not nice, but it
seems like the libgcrypt idiom.

However you make me believe we could use uint8_t here?  My KEM API is
not similar to other parts of libgcrypt anyway, so we don't have to
repeat using 'void*' for data.

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

My use was modeled in existing uses like 'enum gcry_cipher_algos', 'enum
gcry_pk_algos' etc.  I do agree with you, but I think consistency is
also important.

> 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)

I think either a context handle or algorithm identifier is needed.  The
key parameter is just a opaque byte array, it doesn't know its
algorithm.

> 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.

That was my first version of the API.  It felt useless to have all these
size_t lengths and checks for them since they were all fixed strings
anyway.  Let's see where all other issues end up, if this is still
relevant.

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

My approach uses raw keys directly, so this is included.

/Simon
-------------- 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/20230519/0550ba14/attachment.sig>