Mon, Dec 4
You may better ask on gcrypt-devel at gnupg.org for help.
Fri, Dec 1
Thu, Nov 30
Tue, Nov 28
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?
Mon, Nov 27
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.
Thu, Nov 16
Wed, Nov 15
RSA improvement is not that worth now.
OK. When we will need and do, I will open new one.
The fix is in 1.10.3.
Fix is in 1.10.3.
Tue, Nov 14
@gniibe: This is a pretty old bug; given all the changes of the last year, should we close it now.
Oct 31 2023
In master, when fixing padding issue, libgcrypt/src/const-time.h is just introduced.
I will replace your functions.
Oct 24 2023
Oct 23 2023
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 18 2023
@jukivilli I have addressed a number of your comments now. You find my comments inline.
Oct 17 2023
Oct 16 2023
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).
Actually we never use uint8_t* because that is c99 and very uncommon except for some MCU projects. Instead we use unsigned char *. The use of void* is often used because this allows to pass arbitrary types to a function without requiring ugly and error-prone casting at the caller site.
You don't need a library but just one object file.
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:
@fse: Github is not an option here. We don't use it and thus everything relevant to Libgcrypt needs to be documented here and not at some external platform.
For length information, we can find that Simon's patch (let me call it v1) has length argument:
Oct 15 2023
- There's many functions that use buffers on stack. Do those contain secrets? Should those buffers be wiped before returning from function (with wipememory())? For example, "mlkem_check_secret_key" has two buffers "shared_secret_1" and "shared_secret_2" which are not wiped.
- mlkem.c: mlkem_check_secret_key: "memcmp" is used to compare shared secrets. Should this use constant time comparison instead?
- mlkem-common.c: _gcry_mlkem_mlkem_shake256_rkprf:
- _gcry_md_hash_buffers_extract can be used here instead of _gcry_md_open&write&extract&close.
- mlkem-symmetric.c: _gcry_mlkem_shake256_prf:
- _gcry_md_hash_buffers_extract can be used here instead of _gcry_md_open&write&extract&close. Temporary buffer usage can be avoided by passing input buffers through two IOV to _gcry_md_hash_buffers_extract.
Few comments on the patches.
Oct 11 2023
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.
@fse Thank you for your comment (quick ! :-).
Oct 10 2023
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 9 2023
Please send us patches (to this branch).
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 6 2023
Pushed the change into kem-kyber branch.