Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

GHP18 analysis may not apply #92

Open
chris-wood opened this issue Nov 14, 2024 · 0 comments
Open

GHP18 analysis may not apply #92

chris-wood opened this issue Nov 14, 2024 · 0 comments

Comments

@chris-wood
Copy link

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:

ct = CompositeCiphertextValue(mlkemCT, tradCT)
ss = KDF(mlkemSS || tradSS || tradCT || tradPK || Domain)

whereas for equivalence one would need to do something like:

ct = CompositeCiphertextValue(mlkemCT, tradCT)
ss = KDF(mlkemSS || tradSS || ct || tradPK || Domain)

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant