Page MenuHome GnuPG

fse (Falko Strenzke)
User

Projects

User does not belong to any projects.

User Details

User Since
Oct 2 2023, 4:55 PM (34 w, 1 d)
Availability
Available

Recent Activity

Jan 17 2024

fse added a comment to T6637: PQC for Libgcrypt.

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.

Jan 17 2024, 2:24 PM · PQC, libgcrypt

Nov 28 2023

fse added a comment to T6637: PQC for Libgcrypt.

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?

Nov 28 2023, 1:21 PM · PQC, libgcrypt

Nov 27 2023

fse added a comment to T6637: PQC for Libgcrypt.

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.

Nov 27 2023, 4:30 PM · PQC, libgcrypt

Oct 24 2023

fse added a comment to T6637: PQC for Libgcrypt.

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

Oct 24 2023, 1:34 PM · PQC, libgcrypt

Oct 18 2023

fse added a comment to T6637: PQC for Libgcrypt.

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

Oct 18 2023, 1:33 PM · PQC, libgcrypt

Oct 16 2023

fse added a comment to T6755: libgcrypt: KEM API.

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

Oct 16 2023, 1:43 PM · PQC, libgcrypt
fse added a comment to T6637: PQC for Libgcrypt.

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.

Oct 16 2023, 12:07 PM · PQC, libgcrypt
fse added a comment to T6755: libgcrypt: KEM API.

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

Oct 16 2023, 12:01 PM · PQC, libgcrypt
fse added a comment to T6637: PQC for Libgcrypt.

Hi Jussi,

Oct 16 2023, 8:37 AM · PQC, libgcrypt

Oct 11 2023

fse added a comment to T6755: libgcrypt: KEM API.

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.

Oct 11 2023, 8:34 AM · PQC, libgcrypt

Oct 10 2023

fse added a comment to T6755: libgcrypt: KEM API.

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.

Oct 10 2023, 9:11 AM · PQC, libgcrypt

Oct 9 2023

fse added a comment to T6637: PQC for Libgcrypt.

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?

Oct 9 2023, 8:18 AM · PQC, libgcrypt

Oct 4 2023

fse added a comment to T6637: PQC for Libgcrypt.

Uploading two patches for review:

Oct 4 2023, 8:11 AM · PQC, libgcrypt