Hi David, yes, we would like to get all the round 2 submissions in here. But I'd suggest holding off until after the round 2 deadline (March 15) in case the authors are making tweaks, to avoid potentially wasting work.
Proposal: add NTRU LPRime implementation
Would there be interest in the submission of an NTRU LPRime implementation to the master branch? NTRU LPRime is a round two KEM candidate in the NIST competition.
Assuming I can get a clear answer from the authors (Bernstein et al) on the license that applies to their reference implementations, would you be interested in such a contribution? I'm thinking this would be a drop-in of the reference implementation, adjusted as necessary to meet the requirements for your master branch.
The motivation for this is our desire to use NTRU LPRime (in hybrid mode) with TLS for some research work we are doing. Step one would be contributing NTRU LPRime to liboqs. Step two would be making contributions to your OpenSSL fork.
I'm proposing NTRU LPRime rather than Streamlined NTRU Prime, since the metrics on their home page suggest NTRU LPRime offers faster performance for a key gen, followed by encaps and decaps. Given our use case is TLS, this is the primary "round trip" we'd like to optimise for.
8条回答 默认 最新
- 点赞 评论 复制链接分享
I'm actually Duncan :-)
I've ported the implementation and all seems well, however I haven't heard back from any of the authors regarding licensing. It's not clear what license applies to the SUPERCOP reference implementation.
If anyone reading this has better connections with the team behind NTRU LPRime, I'd welcome some assistance in clarifying this. Until I know better, I don't think I can open a merge request to add it.点赞 评论 复制链接分享
I've sent an email to Dan Bernstein to ask what license the original implementation is under and will let you know what I hear.点赞 评论 复制链接分享
I've received confirmation from Dan Bernstein that their NTRU LPRime implementation is in the public domain.点赞 评论 复制链接分享
Great, thanks . I'll raise a PR in the next few days.点赞 评论 复制链接分享
We're actually trying a new approach for the Round 2 submissions. We have developed a sister project, PQClean, which is meant to contain standalone C implementations of individual PQ algorithms; that repository has lots of automated tests that are run on the code on more platforms than we are testing liboqs on at the moment. But PQClean is not a library, it's standalone implementations; liboqs will wrap them all together in a library, and then continue with the TLS/SSH/... prototypes.
Last night I actually spent a couple of hours preparing one of the NTRU Prime algorithms (ntrulpr653) for PQClean based on the Round 2 submission ZIP. I think that first algorithm is mostly done (see branch), and now it's a matter of doing the remaining NTRU LPR and Streamlined NTRU algorithms for PQClean. Once they're in PQClean, it's pretty straightforward to add to liboqs.
Would you want to finish off the NTRU Prime algorithms for PQClean? We can have a quick call or email exchange if you want more of an explanation.点赞 评论 复制链接分享
Would you want to finish off the NTRU Prime algorithms for PQClean?
Sure, I'd be happy to take a look at that.点赞 评论 复制链接分享
Ah, looks like you've already added the remaining LPRime algorithms, which is where our interest lies. Let me know if I can help with any remaining work to bring this into liboqs.点赞 评论 复制链接分享