I just saw that Niibe is already working on the integration of the ML-KEM code into the master branch of libgcrypt. Apparently, this is an entirely new code base. Currently we are working on the integration of our ML-KEM implementation in libgcrypt into GnuPG. But based on what I see now it seems that apparently another approach is planned and already underway for libgcrypt and probably later also for GnuPG. It would be helpful if you could give us a pointer what your exact plans are, this makes it easier for us to direct our efforts in the optimal way.

And another question: in the GnuPG code on the master branch I saw that algorithm identifiers for ML-KEM with Ed25519 and Ed448 are already defined in the code base. Do I understand correctly that the maintainers prefer the inclusion of these two algorithms and not necessarily the inclusion of the ones based on ML-KEM with ECDH using NIST or Brainpool curves?

We have addressed all comments regarding ML-KEM (Kyber) and KMAC. Currently I am working on the GnuPG integration of the the ML-KEM composites. For that purpose I will need a branch of libgcrypt with both ML-KEM and KMAC. I am not sure if you are considering to integrate the ML-KEM version already now before the final NIST standards are release. Some libraries do it, for instance Botan. Appropriate naming of the algorithms can ensure that there arises no confusion which version of the algorithm one is using.

In T6637#177217, @jukivili wrote:

Yes, int8_t/int16_t/int32_t/uint8_t/uint16_t/uint32_t should not be used. There is size-specific integer types defined in src/types.h which can be used instead (byte/u16/u32). This header does not yet have signed integer types, but those can be added (for example, s8/s16/s32).

@jukivilli I have addressed a number of your comments now. You find my comments inline.

Yes, apparently I confused uint8_t and unsigned char here because the former appears in Simon's comments. We also kept to the use of unsigned char* in our implementations (that is even part of the GNU coding guidelines if I remember correctly).

OK, fine, however, in order to be able keep an overview of our tasks I would still keep track of them in our GitHub, where I can create a sub-issue from the list of tasks with one click. But we will post our comments and results here as well as far relevant for the purpose of documentation. I think most of the points Jussi raised are more or less clear to me anyway.

With respect to the function signatures, I see the following issues with the API you reference via the provided link:

Hi Jussi,

Our own internal function signatures is not necessarily a good refernce. The main objection to all what you list above is the lack of explicit length information. For each uint8_t* there should also be a size_t ...len in my opinion. Otherwise the API will be highly prone to memory access errors.

The API that you quote at the end is indeed what is comonly understood as how a KEM functions and is exactly what fits to ML-KEM.

One question on the future cooperation: is it from now on possible to directly commit to these branches or will we continue to work with uploading patches to this task?

Uploading two patches for review: