On 2 May 2024, at 07:42, Werner Koch via Gnupg-devel <[email protected]> wrote:
> +Curve | ML-KEM | ECC-KEM | SHAFunc | Requirement > +---------------:|--------|---------|----------|------------ > +X25519 | 768 | XKem | SHA3-256 | SHOULD > +X448 | 768 | XKem | SHA3-512 | MAY > +X25519 | 1024 | XKem | SHA3-256 | MAY > +X448 | 1024 | XKem | SHA3-512 | SHOULD > +brainpoolP256r1 | 768 | ecdhKem | SHA3-256 | MAY > +brainpoolP384r1 | 768 | ecdhKem | SHA3-512 | SHOULD > +brainpoolP512r1 | 768 | ecdhKem | SHA3-512 | MAY > +brainpoolP512r1 | 1024 | ecdhKem | SHA3-512 | SHOULD > +brainpoolP256r1 | 1024 | ecdhKem | SHA3-256 | MAY > +brainpoolP384r1 | 1024 | ecdhKem | SHA3-512 | MAY > +NIST P-256 | 768 | ecdhKem | SHA3-256 | MAY > +NIST P-384 | 768 | ecdhKem | SHA3-512 | MAY > +NIST P-521 | 768 | ecdhKem | SHA3-512 | MAY > +NIST P-256 | 1024 | ecdhKem | SHA3-256 | MAY > +NIST P-384 | 1024 | ecdhKem | SHA3-512 | MAY > +NIST P-521 | 1024 | ecdhKem | SHA3-512 | MAY This is an enormous set of initial combinations, not all of which make any sense. Why suggest pairing P-256 curves with kyber1024? Do we need all three grades of brainpool and NIST? The four SHOULDs and the corresponding two NIST equivalents are plenty. Once again I’ll beg you to please implement the Kousidis, Strenzke and Wussler spec instead of making trivial changes to their assigned numbers in order to start a pointless and exhausting fight with the IETF WG over ownership of the registry. If we need to allocate four more code points for the brainpool and nist alternatives, what’s the harm? The registry is SPECIFICATION REQUIRED (or will be shortly) and the use of brainpool/nist curves in PQC is not controversial. Why reinvent the wheel? A
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ Gnupg-devel mailing list [email protected] https://lists.gnupg.org/mailman/listinfo/gnupg-devel
