> > This reduces load on security reviewers: everyone can see that the full
> > ct is included in the hash, without having to worry about KEM details.
> Here I disagree: the security analysis needs to be done *once* (and
> has been done, but of course still needs review; ideally also
> computer-verification).
To clarify, what I'm talking about is the extra review load that comes
from having more combiners than necessary in the ecosystem.
For example, if Situation A asks security reviewers to look at a generic
combiner, and Situation B asks security reviewers to look at a generic
combiner _plus_ a 20-page paper about a Kyber-specific combiner, then
Situation A clearly reduces review load compared to Situation B.
In Situation A, with the combiner that I'm talking about, everyone can
look at the hybridss formula and immediately see that everything is
hashed in. In Situation B, reviewers have to look at the generic formula
_and_ look at how Kyber details interact with another combiner.
Of course we hope that any particular piece of security review can be
done just once and that's the end of it (OK Google, please read once
through the Chrome source code and remove the buffer overflows), but the
bigger picture is that many security failures are easily explained by
reviewer overload, so minimizing the complexity of what has to be
reviewed is a useful default policy. Minimizing TCBs is another example
of the same approach.
> if we manage to eliminate a significant (albeit not huge)
> amount of cycles through a careful security analysis that needs to be
> done once, I expect this to be helpful for adoption.
I don't see how this argument survives quantification regarding the
hashes that we're talking about. Sending 1KB of ciphertext has roughly
the same dollar cost as 2 million CPU cycles; why would the application
care about a combiner spending 10000 or even 20000 cycles on hashing?
Another way to save a similar amount of CPU time would be to use a
universal hash to compress the input to Kyber's implicit-rejection hash
("J"). This has well-known proofs, and it can be decided separately by
each secret key without any interoperability issues---but I don't see
how applications would care: the KEM bottleneck is the communication
cost, not the cycle count.
> > It also reduces risks for people who rip out the KEM (for example,
> > because of patent concerns) and swap in another KEM.
> This is why it's very important to standardize (and communicate) X-Wing
> as a KEM, not as a combiner.
And yet the combiner appeared explicitly in the first message in this
thread! I do think that adding enough warnings can reduce risks, but
it's even better to take the sharp edges out of the underlying tool.
---D. J. Bernstein
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
