Aligned with X-Wing #11
Conversation
draft-ietf-lamps-pq-composite-kem.md
Outdated
|
|
||
| ### Ciphertext collision resistance {#sec-cons-ct-collision} | ||
|
|
||
| The notion of a ciphertext cellision resistant KEM is defined in [X-Wing] being the property that it is computationally difficult to find two different ciphertexts that will decapsulate to the same shared secret under the same public key. In [X-Wing] it is proven that ML-KEM has this property and therefore the ML-KEM ciphertext can safely be omitted from the KEM combiner. Similarly, RSA-KEM {{I-D.ietf-lamps-rfc5990bis}} is a bijective map between the shared secret `Z` and the ciphertext `C` and so is naturally immune to ciphertext collision. This leaves only ECDH, X25519 and X448 which are not ciphertext collision resistant and for which the ciphertexts need to be included in the derivation of the shared secret. |
There was a problem hiding this comment.
Similarly, RSA-KEM {{I-D.ietf-lamps-rfc5990bis}} is a bijective map between the shared secret
Zand the ciphertextCand so is naturally immune to ciphertext collision. This leaves only ECDH, X25519 and X448 which are not ciphertext collision resistant and for which the ciphertexts need to be included in the derivation of the shared secret.
I am not sure I get that. Why is RSA-KEM in rfc5990bis CCR?
rfc5990bis defines
CEK <- random 256-bits
z <-$ [0, n);
c <- z^e mod n;
WK <- ENCRYPT(KDF(z), CEK);
CC <- (WK, c)
RSA-ENCAPS(pubkey=(e,n)) := (CC, CEK)
Someone that can break c or WK can produce a different CC' which leads to the same CEK by producing a different value of c. ML-KEM did not have that issue because there is only one random m used for the encapsulation.
There was a problem hiding this comment.
Isn't the definition of CCR that we care about here that you can't have z -> c and z' -> c where z != z' ? Since we're not borrowing the symmetric WRAP primitive from 5990, I don't see why that matters?
draft-ietf-lamps-pq-composite-kem.md
Outdated
|
|
||
| Still to do in a future version: | ||
|
|
||
| `[ ]` We need PEM samples … 118 hackathon? OQS friends? David @ BC? The right format for samples is probably to follow the hackathon ... a Dilithium or ECDSA trust anchor certificate, a composite KEM end entity certificate, and a CMS EnvolepedData sample encrypted for that composite KEM certificate. | ||
|
|
||
| `[ ]` Open question: do we need to incluede the ECDH, X25519, X448, and RSA public keys is the KDF? X-Wing does, but previous versions of this spec do not. |
There was a problem hiding this comment.
This is a good question, not sure yet
Co-authored-by: Deirdre Connolly <[email protected]>
… into mikeo_xwing
|
Closes #13 |
draft-ietf-lamps-pq-composite-kem.md
Outdated
|
|
||
| ### Ciphertext collision resistance {#sec-cons-ct-collision} | ||
|
|
||
| The notion of a ciphertext cellision resistant KEM is defined in [X-Wing] being the property that it is computationally difficult to find two different ciphertexts that will decapsulate to the same shared secret under the same public key. In [X-Wing] it is proven that ML-KEM has this property and therefore the ML-KEM ciphertext can safely be omitted from the KEM combiner. Similarly, RSA-KEM {{I-D.ietf-lamps-rfc5990bis}} is a bijective map between the shared secret `Z` and the ciphertext `C` and so is naturally immune to ciphertext collision. This leaves only ECDH, X25519 and X448 which are not ciphertext collision resistant and for which the ciphertexts need to be included in the derivation of the shared secret. |
There was a problem hiding this comment.
I'm just looking at this now, so apologies if I'm mistaken. But I think the argument that the mapping between RSA ciphertext and plaintext is bijective only holds once you fix the modulus. So I think you would need some binding to the modulus in the KDF input to achieve bijectivity. (But do not take this as a proof that it's okay if you have this -- would need more careful consideration than I've given it so far.)
There was a problem hiding this comment.
To err on the safe side, this has been changed to:
Ciphertext collision resistance is not guaranteed for either RSA-KEM or ECDH, therefore these ciphertexts are bound to the key derivation.
|
Should align with the openpgp-pqc draft: See parallel github issue: |
|
TODO: this is a massive PR. Review again when I'm less sleep-deprived. |
No description provided.