On Sat, Jan 27, 2024 at 02:56:45PM -0000, D. J. Bernstein wrote: > David Benjamin writes: > > No more heavily parameterized algorithms. Please precompose them. > > > > Once you precompose them, you may as well take advantage of properties > > of the inputs and optimize things. > > In my implementor's hat, I partially agree. Knowing the context often > enables speedups that aren't available in more generality, as long as > the implementation isn't factored into context-independent pieces. > > However, at the design stage, speedups have to be weighed against other > considerations, such as overloading security reviewers and introducing > unnecessary traps into the ecosystem.
Security review of X-wing only needs to be done once. I think generic combiner would be the unnecressary trap. Generic combiner would likely lead to lots of combinations. Something multiple crypto library maintainers have said they don't want. And overloading crypto library maintainers is far worse than overloading security reviewers. And I think it much easier to understand integrated thing that is unsafe to change than that the component KEMs must be <some-gibberish> (oh, and then being used with stuff that fails the requirement). And things are made worse by different protocols tending to do things subtly differently even when using the same KEMs. None of this is theroretical risk, this all has been seen in practice. Unlike unsafe modified versions of X-Wing. > The particular speedup we're talking about here is eliminating hashing a > kilobyte or two of data. In context, this speedup is negligible: about > 1% of the cost of communicating that data in the first place, never mind > other application costs. The cost is not negligible. > There's a 20-page paper saying that this tiny speedup is safe _for > Kyber_. Why exactly do we want security reviewers spending time on this? > And why should this be sitting around in the ecosystem, given the clear > risk of someone plugging in something other than Kyber? Not all of that is security proofs, and the part about the speedup is like 1.3 pages of simple rather sparsely spaced text. And there are even simpler ways of proving the same thing. Looking at other stuff in the paper, there is about 2.3 pages of much more complicated text proving that using X25519 is safe at all! Which is something that generic composition does not even consider, and this matter is not trivial. If somebody starts blindly replacing algorithms, there is much higher risk of actual security problem caused by choosing bad algorithms than omitting some hashing. No real attacker is looking how to break IND-CCA. They are looking at how to attack actual systems. The value of IND-CCA is that despite unrealistically strong attack model, most algorithms that fail it tend to fail in rather dangerous ways. Which is not at all clear for combiner with insufficient hashing. -Ilari _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
