On Fri, Feb 21, 2020 at 1:37 PM Stephen Farrell <[email protected]> wrote: > > > Hiya, > > On 21/02/2020 21:24, Scott Fluhrer (sfluhrer) wrote: > > What it tries to address is "once we have an > > approved algorithm, how do we integrate it into TLS". > > Except that we do not have an approved algorithm. We have > 17 round 2 KEMs with vastly different properties. Even > when NIST are done that number seems likely to be >1.
All the KEMs are KEMs, meeting the same security properties, and fall into three categories of problem: lattice, code, and isogeny. > > > Surely it > > would be better to get that preliminary work out of the way first, > > rather than waiting for the NIST process to conclude, and then start > > spending the time working on the integration process. > Given the range of differences in sizes of public values, > CPU etc and the fact that we don't know how those algs > will be parameterised, I don't believe this is work that > can be usefully gotten out of the way first. We have already deployed widespread experiments that conducted the hybridization described in this draft, already have implementations supporting an approach similar to this draft, and that produced valuable input to the standardization process. It really didn't matter that it was SIKE or NewHope that was being hybridized, and they have very different characteristics. What will we know when NIST finishes that we need to know that we do not know today? Which algorithm we want to hybridize? That's easy to handle: the mechanism is generic. Sincerely, Watson Ladd _______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
