[PATCH] Add Streamlined NTRU Prime sntrup761.

[Stephan Müller]

Am Freitag, 19. Mai 2023, 23:52:00 CEST schrieb Simon Josefsson:

Hi Simon,

> Stephan Mueller <smueller at chronox.de> writes:
> >> gcry_error_t gcry_kem_enc (int algo,
> >> 
> >> 			   const void *pubkey,
> >> 			   void *ciphertext,
> >> 			   void *ss);
> > 
> > May I suggest to add another parameter: size_t ss_len which shall specify
> > the caller-requested size of ss?
> 
> Is that to support variable-length outputs?  Or just to indicate the
> buffer size?  Does kyber or some other popular KEM supports
> variable-length outputs?

Short answer: this is to indicate variable length outputs.

Long answer: Kyber KEM defines as its last step a KDF using either SHAKE256. 
Both KDFs allow the caller to request an arbitrary output size. Yet, the 
sample source code generates hard-coded 32 bytes.

To avoid waste of CPU cycles and considering that both KDF operations are 
defined as pseudorandom operations (see SP800-185 for SHAKE), I personally 
think that this KDF should be asked to generate exakt those number of bytes 
that are needed. This implies that I added the ss_len parameter to my API set 
to advertise that this helps preventing the waste of precious CPU cycles.
> 
> >> gcry_error_t gcry_kem_dec (int algo,
> >> 
> >> 			   const void *ciphertext,
> >> 			   const void *seckey,
> >> 			   void *ss);
> > 
> > Same here.
> > 
> > Kyber uses a KDF as the last step. I am aware of the fact that the Kyber
> > reference implementation returns 32 bytes statically. However, considering
> > the use of a true KDF which has the property of a pseudorandom behavior
> > (either SHAKE256 or AES-CTR is used), the KDF can produce arbitrary
> > amounts of data. By specifying an ss_len parameter, the caller can
> > directly request the data that may be needed as a key/IV/mac Key or
> > similar for subsequent cipher operations.
> 
> What does the specification says?  Is kyber specified as a
> variable-length output, or output of 32 bytes?

The specification contains the following words regarding the KDF:

"""
As a modification in round-2, we decided to derive the final key using 
SHAKE-256 instead of SHA3-256.
This is an advantage for protocols that need keys of more than 256 bits. 
Instead of first requesting a 256-bit
key from Kyber and then expanding it, they can pass an additional key-length 
parameter to Kyber and
obtain a key of the desired length. This feature is not supported by the NIST 
API, so in our implementations
we set the keylength to a fixed length of 32 bytes in api.h.
"""

So, the authors deem it as acceptable to specify an ss_len.
> 
> One approach is to have another API for that use-case:
> 
> gcry_error_t gcry_kem_enc_kdf (int algo,
> 			      const void *pubkey,
> 			      void *ciphertext,
> 			      size_t sslen, void *ss);
> gcry_error_t gcry_kem_dec_kdf (int algo,
> 			       const void *ciphertext,
> 			       const void *seckey,
> 			       size_t sslen, void *ss);

Fine with me, too
> 
> /Simon


Ciao
Stephan