IND-CCA2 for ECC-KEM and KEM Combiner

[fluppe2]

What has been added or changed:

a) Pointed to the Bertoni/Daemen/Peters/Assche paper "On the Indifferentiability of the Sponge Construction" for Keccak since this has a stable DOI b) Defined IND-CCA2 secure KEM combiner according to the Giacon/Heuer/Poettering paper "KEM Combiners" and added security considerations for this c) Aligned x25519kem and x448kem to RFC7748, splitted the description to be more readable d) Defined IND-CCA2 secure ECC-KEMs according to the Cramer/Shoup paper "Design and Analysis of Practical Public-Key Encryption Schemes Secure against Adaptive Chosen Ciphertext Attack" and added security considerations for this e) Removed the words "native", "masking", "clamping" concerning x25519, x448 as they are nowhere defined and might not be comprehensible, instead defined to simply follow the encodings of RFC7748 f) Added "oBits=256" into the call of "multiKeyCombine" of the composite KEM encryption and decryption procedure as the KEK needs to be specified

@wussler: Are you okay with c) and e)?

@ahuelsing: Are you okay with a)? Can you check b)? Can you check also d)?

@falko-strenzke, @TJ-91: Are you okay with f)? What did you guys implement? Did you implicitely assume this?

[TJ-91]

@falko-strenzke, @TJ-91: Are you okay with f)? What did you guys implement? Did you implicitely assume this?

I think the clarification is useful 👍 Since we use AES-256 key wrap, this is the only possible size for the KEK. Making it explicit is better.

[fluppe2]

Let me try to explain my approach with an IND-CCA2 version of the ECC-KEMs in conjunction with the KEM combiner.

• I tried to build this in a modular way, i.e. have CCA2-secure ingredient KEMs and then feed the ciphertexts into the KEM combiner so that the KEM combiner preserves their CCA2-security. The security considerations as they are proposed in this PR are tailored to such a modular approach.
• The hashing in the ECC-KEMs ensures CCA2-security, the hashing is necessary if you want to achieve CCA2-security for the ECC-KEM itself. Only concatenation is not enough for this purpose as an attacker would control changes to the concatenation bitwise, the hashing ensures that changes propagate. Just to be clear, here I am looking only on the ECC-KEM itself.
• Having the hashing step in the ECC-KEMs, I think it is enough to simply input the K1 || C1 || K2 || C2 into the combiner as the lengths of all key shares and ciphertexts are constant depending only on the specific parameters of the ingredient KEMs. We do not have to introduce an additional H(K1||C1) || H(K2||C2) in the combiner.
• If we decide to remove the hashing step in the ECC-KEMs we would have to adopt our security considerations, trying to argue that the combined construction as a whole is (maybe) CCA2-secure, then I would rather suggest to have the KEM combiner processing H(K1||C1) || H(K2||C2), since assuming that K1, C1 come from an ECC-KEM, the hashing step for ECC-KEM would then be performed inside the combiner. Maybe that would allow a security argument that while the ECC-KEM building blocks are only IND-CPA, the construction as a whole would (maybe) ensure IND-CCA2. I don't know. Assuming for the moment that K2, C2 come from Kyber then the additional hashing might be superfluous but relieves an implementer from length checks so might be beneficial.

Just trying to do state-of-the-art crypto. The modular approach allows for nice and clean security arguments backed up by the present scientific literature. The more tailored approach with IND-CPA versions of ECC-KEMs and (potential) CCA2-security established by the KEM combiner could be a bit more involved.

[wussler]

@fluppe2 I addressed the comments we had today in the call, please review the latest changes and when you're OK we can merge :rocket:

Edit: there also is still an open thread from Andreas, but IMO no change is needed there

[fluppe2]

I would say the mentioning of rho is fine for now, I think it is still a moving target how we reference the PQ specs, since we are waiting for the final standards.