Niels Möller <ni...@lysator.liu.se> writes: > Simon Josefsson <si...@josefsson.org> 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.
Sounds good, and the same for non-streamlined NTRU Prime. > So should we focus on getting sntrup761 in as the first post-quantum > key exchange algorithm? +1 >> 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. No objection, but I find it challenging to come up with a revised patch that I feel comfortable with in the near future. I'm not sure I even understood what unused functions you noticed (and how?); that fix would be easy to do. Gaining confidence in rewritten parts feels a bit more complicated. Would you like to revise the code? Maybe we can all review on the list. >> 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). Aligned API/ABI's are nice, and good to get right early. Is 'nettle_block16' still the right way to do this, or is this possible to (with arguably more readable) aligned() or alignof() attributes? /Simon
signature.asc
Description: PGP signature
_______________________________________________ nettle-bugs mailing list -- nettle-bugs@lists.lysator.liu.se To unsubscribe send an email to nettle-bugs-le...@lists.lysator.liu.se
