Adding FAEST

[sebastinas]

I am looking into adding FAEST to liboqs. Since I have last worked with liboqs, the build setup has changed quite significantly. What is the recommended way to add a single implementation to liboqs that provides all variants? All signature schemes using copy_from_upstream have multiple copies of similar/same files. Also, can I get copy_from_upstream to perform pre-configuration steps before copying files?

[sebastinas]

This is related to #2098.

I can add FAEST as it was done for Picnic. If that is still okay with the current setup, I have a PR almost ready to go.

[dstebila]

Hi Sebastian, thanks for offering to do this!

I think the FrodoKEM and stateful signature (LMS / XMSS) code offers examples of having a single implementation that provides all variants via different compile-time macros, using a code base that's directly added to liboqs.

But more recently we have been tending to using the copy_from_upstream scripting to copy an "upstream" implementation and use code generation to generate the relevant hooks into liboqs code. A side-effect of this approach is that we get multiple copies of similar/same files. Since we have been focused on providing a platform for testing/experimentation, we haven't been so worried about that duplication.

can I get copy_from_upstream to perform pre-configuration steps before copying files?

We have a mechanism for copy_from_upstream to patch files after copying, but we don't have anything for modifying things before copying. In principle the script can be extended to do that, though it's already grown into some rather messy, I think. What would you like to be able to do?

[SWilson4]

Hi @sebastinas, is this still something you're looking to do?

[sebastinas]

It is still on my todo list but I was busy with other stuff.

[aneale1]

Hello @sebastinas

My name is Arpad Neale and I just finished my Master's degree where I studied applied cryptography. I'm new to liboqs and I'm looking to work on the integration of the NIST signature on-ramp round 2 candidates. I attended the OQS status meeting on Nov 18th and heard that there was interest in integrating FAEST. How is the integration going, and are there any to-dos that you would like some help with?

I wanted to reach out to introduce myself and offer my help. Unfortunately, I won't be consistently available until December 1st due to travel and the Thanksgiving holidays. In the meantime, I'll continue studying liboqs, its workflows, and the upstream FAEST project.

Best regards,
Arpad Neale

[sebastinas]

@aneale1 The FAEST implementation at https://github.com/faest-sign/faest-ref should be ready to be integrated into liboqs in a similar way that the integration of Picnic was done. The only missing bit - I think - is that the code base does not use AES from liboqs.

There are however some things that need to be taken care of on the liboqs side:

• OQS needs to be defined so that FAEST uses functions from liboq (see compat.h)
• Some checks from its meson.build will need to be translated to cmake for liboqs - see all the checks for HAVE_* without a counterpart in liboqs.
• Some of the files are generated during the build. Either the generated files are copied to liboqs or the logic to generate them is also tranlsated to cmake

If you have any questions on the upstream code, feel free to get in contact with me. We can also schedule a call.

[aneale1]

hello @sebastinas,

Thank you for reaching out. I'll start looking through the code tomorrow and this weekend. I'll gather questions and reach out to schedule a time to meet.