Scott Fluhrer (sfluhrer) writes:
> If we have a combiner with a proof that âif either of the primitives
> we have meet security property A, then the output of the combiner
> meets security property Bâ, and we have proofs that both our
> primitives meet security property Aâ, then doesnât that mean that our
> system has a proof that it meets security property B?
Certainly those proofs would compose. Even better, _one_ of the
primitives having property A would be enough.
However, the logic relies on a match between the two A properties that
you mention: the property provided by the KEMs, and the property assumed
by the combiner. The situation is different when
* KEM designers and reviewers focus primarily on IND-CCA2, and then
* a combiner comes along requiring its input KEM to provide some
property _beyond_ IND-CCA2.
Then more review time is needed to see which KEMs have that property.
There's no reason to think that KEMs will always have that property.
There's a clear risk of people making the mistake of using the combiner
with a KEM that doesn't have that property.
We already know how to avoid this risk by changing the combiner to hash
more data, as in the
hybridss = H(ECDHss,KEMss,H(hybridct),H(hybridpk),context)
construction that I mentioned before. Sure, for Kyber this is kilobytes
of extra hashing; how can this matter next to the cost of communicating
those kilobytes through the Internet in the first place?
Note also that real KEMs _aren't_ proven to be IND-CCA2 (never mind
properties beyond IND-CCA2); they aren't even proven to resist a
narrower class of attacks, namely QROM IND-CCA2. For example,
https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/C0D3W1KoINY/m/GuWevJfPAQAJ
plausibly claims provability for the statement that an attacker limited
to (say) 2^90 hash calls can't carry out a high-probability QROM
IND-CCA2 attack against Kyber _if_ the attacker can't carry out an
IND-CPA attack with probability around 2^-92---but there's no proof that
such a low-probability IND-CPA attack is hard. Right now one can't even
find a clear statement of the resources required for the best _known_
low-probability IND-CPA attack.
---D. J. Bernstein
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
