cipher:kem:ecc: Support NIST curves.
Audited005292cf9f41
Actions

Description

cipher:kem:ecc: Support NIST curves.

* cipher/kem-ecc (ECC_SECKEY_LEN_MAX): Fix for P521R1.
(algo_to_curve): Using canonical name, add NIST curves,
(algo_to_seckey_len): Likewise.
* cipher/kem.c (_gcry_kem_keypair, _gcry_kem_encap): Likewise.
(_gcry_kem_decap): Likewise.
* src/gcrypt.h.in (enum gcry_kem_algos): Likewise.

GnuPG-bug-id: T6815
Signed-off-by: NIIBE Yutaka <gniibe@fsij.org>

Details

Auditors

• werner

Provenance

• gniibe

Authored on Apr 24 2024, 3:28 AM

Parents

rC118fa95d8d36: cipher:kem:ecc: Fix DHKEM implementation.

Branches

Unknown

Tags

Unknown

Tasks

T6815: PQC encryption for GnuPG

Event Timeline

• gniibe committed rC005292cf9f41: cipher:kem:ecc: Support NIST curves. (authored by • gniibe).Apr 24 2024, 3:28 AM

• gniibe added a task: T6815: PQC encryption for GnuPG.Apr 24 2024, 4:19 AM

• werner added a subscriber: • werner.Apr 24 2024, 8:54 AM

• werner added inline comments.

/src/gcrypt.h.in
1724	Sure that the NISt curves should be named P256R1 ? irrc, the r1 suffix is only used with brainpool curves. Shouldn't we just name them `NISTP256` etc? The identifiers won't be longer than the MLKEM1024.

• gniibe marked an inline comment as done.Apr 25 2024, 2:07 AM

• gniibe added inline comments.

/src/gcrypt.h.in
1724	After some thought, I had decided this name. But, I don't have strong opinion for the names and open to changes. FYI, my thought was: Some people prefer the name as SECP256R1 instead of NISTP256, perhaps, care about the origin. In SEC standard, there is another version with a prime field, SECP256K1, which is used by bitcoin, and available in libgcrypt. We need to distinguish them. `NISTP256` is too long when it is used for DHKEM with `GCRY_KEM_DHKEMNISTP256_SHARED_LEN` (> 31 chars)