Simon Josefsson <[email protected]> writes: >> In general, it makes sense to add support for post-quantum key exchange >> methods, another candidate seems to be https://classic.mceliece.org/ >> (with the drawback of much larger pubkeys). > > +1
I've been asking some other people too. sntrup seems to be a good option. Classic mcelice makes sense too, with a different underlying problem, and a different tradeoff (possible more conservative security, but larger pubkeys). Other NIST candidates Saber and Kyber I'm told have some patent issues, so I prefer not to touch them until that has been sorted out. So should we focus on getting sntrup761 in as the first post-quantum key exchange algorithm? >>> Please consider it a first iteration for early review. >> >> I initially looked at the arithmetics. The signed (int32) sorting and >> division seems unused? > > Do you mean crypto_sort_int32? It is called by crypto_sort_uint32. And int32_divmod_uint14 looked unused. For sorting, it may need a minor reorg to get rid of the unneeded variant. >> For the side-channel silent divmod function, it seems we divide >> exclusively with one or a few constants, then we could precompute >> needed constants and perhaps simplify a bit. > > Possibly - this is reference code and supports other sntrup lengths. > Supporting multiple lengths often leads to complexity which leads to > reduced security. As far as I can tell, the non-sntrup761 lengths were > insisted upon by NIST. So the answer depends on if we want to allow > this code to be re-used by other sntrup lengths too. One doesn't have to hard code a single divisor. I'm thinking of precomputing the reciprocal (and any other magic constant depending on the divisor), currently done at runtime as uint32_t v = 0x80000000; v /= m; (unless compiler does lots of inlining). > Also, do we want to deviate from audited implementations? Good question. I think the answer is yes. Some considerations: * We need proper tests for changes, including side-channel things that can be tested with valgrind. * If I have to choose between audited code and readable code, I think I would usually go for the latter. * It's nice to have code consistent with general style in Nettle. And more importantly, run-time selection of code should be done with the same fat machinery as for other algorithms. * To me, it seems unlikely that we could wrap the audited reference implementation in a way that is both practical, and makes the audit provide significant confidence in the complete Nettle implementation. > My take was that it would be nice to add sntrup761 to Nettle ASAP to > stabilize API and establish support for the algorithm -- we can optimize > or improve the implementation later on (there are many optimized > implementations around for different architectures out there). Makes sense, if it's clear what api and abi should look like (but, e.g., use of union nettle_block16 does affect the abi, I think). Regards, /Niels -- Niels Möller. PGP key CB4962D070D77D7FCB8BA36271D8F1FF368C6677. Internet email is subject to wholesale government surveillance. _______________________________________________ nettle-bugs mailing list -- [email protected] To unsubscribe send an email to [email protected]
