The security considerations references GHP18 as proof of the combiner mechanism in the draft. However, as far as I can tell, the draft does not adhere to the construction in this paper. In GHP18, the output ciphertext is the result of concatenating all of the individual KEM ciphertexts, and the shared secret is the result of a function W applied to all individual KEM shared secrets and the ciphertext, i.e., K= W(k1,...,kn,c) where ki is the i-th KEM shared secret and c is the combined (concatenated) ciphertext.
However, in this document, the shared secret does not include the ciphertext in the same way. It computes the shared secret as:
The security considerations references GHP18 as proof of the combiner mechanism in the draft. However, as far as I can tell, the draft does not adhere to the construction in this paper. In GHP18, the output ciphertext is the result of concatenating all of the individual KEM ciphertexts, and the shared secret is the result of a function W applied to all individual KEM shared secrets and the ciphertext, i.e.,
K= W(k1,...,kn,c)wherekiis the i-th KEM shared secret andcis the combined (concatenated) ciphertext.However, in this document, the shared secret does not include the ciphertext in the same way. It computes the shared secret as:
whereas for equivalence one would need to do something like:
Presumably the traditional public key is included for MAL-BIND-K-PK reasons, but it's not really clear to me.
To make a long issue short, where is the proof of security for the combiner in this document?