remove double ECC ciphertext processing in combined KEM

[falko-strenzke]

Quynh reported that the ECC ciphertext in the current design is fed both to the hash internal to the ECC KEM and to the key combiner of the KEM. We should remove one of these.

[falko-strenzke]

Removing the ciphertext from the hashing step in the ECC KEM would be my preferred solution. The reason is that as I understand it, the WG will require a fully generic KEM combiner that will work with any future KEM. So dropping the ciphertext input from the combiner would probably not be the best idea.

In that case we could simply remove the whole hashing step of the ECC algorithm and just feed X (with fixed length) to the KEM combiner, since also the public keys are currently fed into both the ECC hashing step and the KEM combiner.

@QuynhDangNIST Do you agree?

At least I don't see that the ECC-KEM that we define here will be used in any different context so that outputting the raw coordinate X shouldn't be a problem.

[sehlen]

Hi,

since I’m on vacation I won’t look closer into this for now but I think that the ECC-KEM ist modeled after Cramer-Shoup and might need this step to give a CCA-secure KEM. I might of course misremember this but it might be worth checking before any decision is made. Note that we need the CCA security to obtain a CCA-secure hybrid KEM in case Kyber fails.

Stephan

On 8. Jul 2024, at 09:00, Falko Strenzke @.***> wrote:



Removing the ciphertext from the hashing step in the ECC KEM would be my preferred solution. The reason is that as I understand it, the WG will require a fully generic KEM combiner that will work with any future KEM. So dropping the ciphertext input from the combiner would probably not be the best idea.

In that case we could simply remove the whole hashing step of the ECC algorithm and just feed X (with fixed length) to the KEM combiner, since also the public keys are currently fed into both the ECC hashing step and the KEM combiner.

@QuynhDangNIST https://github.com/QuynhDangNIST Do you agree?

At least I don't see that the ECC-KEM that we define here will be used in any different context so that outputting the raw coordinate X shouldn't be a problem.

— Reply to this email directly, view it on GitHub https://github.com/openpgp-pqc/draft-ehlen-openpgp-nist-bp-comp/issues/10#issuecomment-2213190813, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAS3NUIE7SKWPDTD4QBGIFLZLI2JLAVCNFSM6AAAAABKQF6UGGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEMJTGE4TAOBRGM . You are receiving this because you are subscribed to this thread.Message ID: <openpgp-pqc/draft-ehlen-openpgp-nist-bp-comp/issues/10/2213190813@ github.com>

[falko-strenzke]

I think that the ECC-KEM ist modeled after Cramer-Shoup and might need this step to give a CCA-secure KEM. I might of course misremember this but it might be worth checking before any decision is made. Note that we need the CCA security to obtain a CCA-secure hybrid KEM in case Kyber fails.

I think this is satisfied because the KDF given by the KEM combiner (given by SHA3-256) receives both the public keys of both schemes and the ciphertexts of both schemes. So this means the we would actually compute in the KDF:

SHA3-256(counter || X || ss_kyber || ecPublicKey || ecCiphertext || kyberPublicKey ||
kyberCiphertext || algID || domSep || len(domSep) )

where X is the raw shared secret from the ECDH. This construction equally fulfills CCA2 security in my understanding.

[QuynhDangNIST]

Hi all,

The only 1 point I would like to make here is that the KDF suggested in Falko's email below is NIST-compliant.

The counter is allowed to be skipped when the hash function is executed only once as specified on page 159 here: https://csrc.nist.gov/csrc/media/Projects/cryptographic-module-validation-program/documents/fips%20140-3/FIPS%20140-3%20IG.pdf

When X is a pseudorandom key, not a raw shared secret, KMAC-KDF in SP 800-108 (on page 11 here: https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-108r1-upd1.pdf ) is an approved KDF where the Key Derivation Key (K) is a concatenation of multiple pseudorandom keys as specified in Section 6.3 pages 21 & 22 here : https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-133r2.pdf

So, if we delete the step 3 in ECDH-KEM ( Set the output eccKeyShare to Hash(X || eccCipherText || eccPublicKey), then Falko's suggested KDF is NIST-compliant.

If we keep the step 3, eccKeyShare is a pseudorandom key and if eccKeyShare takes the place of X in Falko's suggested KDF, the KDF is not NIST-compliant at this point, but the KMAC-KDF mentioned above is NIST-compliant.

Regards, Quynh.

From: Falko Strenzke @.> Sent: Wednesday, July 10, 2024 2:48 AM To: openpgp-pqc/draft-ehlen-openpgp-nist-bp-comp @.> Cc: Dang, Quynh H. (Fed) @.>; Mention @.> Subject: Re: [openpgp-pqc/draft-ehlen-openpgp-nist-bp-comp] remove double ECC ciphertext processing in combined KEM (Issue #10)

I think that the ECC-KEM ist modeled after Cramer-Shoup and might need this step to give a CCA-secure KEM. I might of course misremember this but it might be worth checking before any decision is made. Note that we need the CCA security to obtain a CCA-secure hybrid KEM in case Kyber fails.

I think this is satisfied because the KDF given by the KEM combiner (given by SHA3-256) receives both the public keys of both schemes and the ciphertexts of both schemes. So this means the we would actually compute in the KDF:

SHA3-256(X || ss_kyber || ecPublicKey || ecCiphertext || kyberPublicKey ||kyberCiphertext || algID || domSep || len(domSep) )

where X is the raw shared secret from the ECDH. This construction equally fulfills CCA2 security in my understanding.

- Reply to this email directly, view it on GitHubhttps://github.com/openpgp-pqc/draft-ehlen-openpgp-nist-bp-comp/issues/10#issuecomment-2219690987, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AFTFKRAN4FRSO24OOYE6S73ZLTKKTAVCNFSM6AAAAABKQF6UGGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEMJZGY4TAOJYG4. You are receiving this because you were mentioned.Message ID: @.***>