Align to NIST PQC Draft Standards FIPS 203, 204, 205

[fluppe2]

Take your time to review and compare with the draft standards. No need to hurry.

The point you to some specifics changes that might be difficult to spot due to the amount of change marks:

• Felt the need to align eccKem.encap()/decap() to the ML-KEM terminology, i.e. switched to ECC-KEM.Encaps()/Decaps() (likewise x25519.Encaps() etc.)

• In Table 9 I spotted some typos (I think). The last colum was „ECDH-KEM curve“, I think it should be consistently „ECC-KEM curve“. In this last column there was X25519, X448 which should be Curve25519 and Curve448.

• In Section 5.1.1 and 5.2.4 it was:

  • "The placeholder eccKem has to be replaced with the specific ECC-KEM from the row "ECC-KEM" of [Table 5], [Table 6], or [Table 7]."
  • "The placeholder kyberKem has to be replaced with the specific Kyber-KEM from the column "Kyber-KEM" of [Table 8]."

  I now borrowed the sentence from the NIST draft standards:

  • "To instantiate ECC-KEM, one must select a parameter set from [Table 5], [Table 6], or [Table 7]."
  • "To instantiate ML-KEM, one must select a parameter set from the column "ML-KEM" of [Table 8]"

• In Section 5.2.4 and 5.2.5 it was:

  • "Instantiate the ECC-KEM eccKem.encap() and the ML-KEM ML-KEM.Encaps() depending on the algorithm ID according to [Table 9]"
  • "Instantiate the ECC-KEM eccKem.decap() and the ML-KEM ML-KEM.Decaps() depending on the algorithm ID according to [Table 9]"

  Felt it somehow doubled to write „instantiate ECC-KEM eccKem.encap()“. I understand that it is meant to establish the mindset „here you need encaps/decaps“. But I don’t know what it means to instantiate an algorithm and felt it better to write

  • „Instantiate the ECC-KEM and the ML-KEM depending on the algorithm ID according to Table 9“

  The next lines in the procedures then say whether to Encaps or Decaps anyway.

• "Binding hashes" for ML-DSA and SLH-DSA: I switched the section title to "Signature Data Digest" to be clearer what we mean. Please take a look at the specific sections if this is ok for you as I wrote it.

Some specific issues that I spotted and not touched but would like to pose them for discussion:

• Is it clear how to encode secret and public key material and ciphertexts/signatures from pointing the reader to the FIPS documents and saying fixed-length octet strings? Or should we list the contents of the specific octet strings or maybe point to the data in the FIPS documents?

• Section 6.2.1 states SHA3-256 as MUST and SHA3-512 as SHOULD, but if one implements ML-DSA-87 then the requirement on SHA3-512 turns into MUST. IS that clear from our formulation?

[fluppe2]

• One occurance of Dilithium is still here: "far greater than those of traditional or Dilithium + ECC signature schemes" (Section 10.1.)

Good catch, aligned in commit 6095c0f.

[fluppe2]

For me it's clear but I see what you mean. Perhaps it makes sense to replace the text by a list that binds each algorithm ID to a hash algorithm, analogous to the SLH-DSA parameters (Table 14). We can also address #57 there (i.e., SHA3-512 is always allowed when SHA3-256 is allowed).

See 16f5b8b

I guess now is a good opportunity to also discuss and close #57?

[falko-strenzke]

Felt it somehow doubled to write „instantiate ECC-KEM eccKem.encap()“. I understand that it is meant to establish the mindset „here you need encaps/decaps“. But I don’t know what it means to instantiate an algorithm and felt it better to write

* „Instantiate the ECC-KEM and the ML-KEM depending on the algorithm ID according to [Table 9](https://github.com/openpgp-pqc/draft-openpgp-pqc/Repositories/draft-openpgp-pqc/draft-wussler-openpgp-pqc.html#tab-mlkem-ecc-composite)“

The "instantiate" terminology is in my understanding indeed a somewhat object oriented concept for the description of the algorithms (in an abstract sense, not with reference to the programming approach). It basically means: "select the set of algorithms / parameters according to the respective KEM (or signature) variant. I still think it can be a valid and intuitively understandable verbal approach if we use it consistently. But I am aware that it is not necessarily the way that specs are typically written and I am also OK with removing the term "instantiate" completely.

[fluppe2]

I guess we are good to go, once the approving reviews come together.

[fluppe2]

To avoid rebasing I adressed #62 in this PR in https://github.com/openpgp-pqc/draft-openpgp-pqc/pull/60/commits/ffbf99672294d5920a02db58b5e9adadbc8fa113. I guess we can close #62.

[TJ-91]

We still have five occurances of "private key". Should we rename them to "secret key" as well?

[fluppe2]

We still have five occurances of "private key". Should we rename them to "secret key" as well?

Fixed in https://github.com/openpgp-pqc/draft-openpgp-pqc/pull/60/commits/e69fe9de058cd9283ba2e9a4e8a0df1d154b8b1f