Improve liboqs integration #7026
Conversation
|
Can one of the admins verify this patch? |
Signed-off-by: Tobias Frauenschläger <t.frauenschlaeger@me.com>
Improve the interface to liboqs by properly configuring and using the RNG provided by WolfSSL from within liboqs. Signed-off-by: Tobias Frauenschläger <t.frauenschlaeger@me.com>
Added a RNG argument to the wc_dilithium_sign_msg method to properly generate necessary random data using the desired WolfSSL RNG object. Signed-off-by: Tobias Frauenschläger <t.frauenschlaeger@me.com>
Added a RNG argument to the wc_falcon_sign_msg method to properly generate necessary random data using the desired WolfSSL RNG object. Signed-off-by: Tobias Frauenschläger <t.frauenschlaeger@me.com>
Added a RNG argument to the wc_sphincs_sign_msg method to properly generate necessary random data using the desired WolfSSL RNG object. Signed-off-by: Tobias Frauenschläger <t.frauenschlaeger@me.com>
When using WolfSSL on zephyr, we need POSIX names for networking systems calls. This can either be enabled with CONFIG_NET_SOCKETS_POSIX_NAMES or with CONFIG_POSIX_API. This commit enables support for the latter. Signed-off-by: Tobias Frauenschläger <t.frauenschlaeger@me.com>
|
As open-quantum-safe/liboqs#1621 is merged now, |
|
@Frauschi that's good news -- thanks for the update. This PR is working its way through our review+testing process and we'll keep you posted. |
|
Hi @Frauschi !! May I ask why you need to wolfSSL's rng facility? Is it something particular about Zephyr? Warm regards, Anthony |
Hi @anhu, The integration of the WolfSSL RNG facility is not directly related to Zephyr. The embedded nature of Zephyr and the hardware platforms it runs on merely increases the need for proper high quality random data, especially as the default random sources of liboqs aren‘t available in embedded environments. Hence, we needed a coupling between liboqs and WolfSSL for our Zephyr platforms anyways. In this context, I thought that a well defined interface between both libraries regarding random data would also benefit other environments like Linux (we also have Linux platforms in our research project) and ease software development. |
There was a problem hiding this comment.
LGTM
There was a trivial rebase conflict in wc_port.c that I've fixed to unblock merge.
Oh, and your choice of wolfcrypt/src/port/ for the liboqs-specific files is consistent with our previous decision to put the af_alg/, aria/, devcrypto/, and kcapi implementations there.
|
Thanks for the feedback and also for the rebase 😄 I‘m happy that this is merged 😄 |
Hi everybody,
this PR improves the integration of liboqs, focussing on two key aspects.
First, I added PQC support for the Zephyr port using liboqs by adding the necessary files to the
CMakeLists.txtfor the Zephyr module. The integration of liboqs as an additional Zephyr module is currently based on a liboqs fork of mine, which I am trying to upstream (see open-quantum-safe/liboqs#1621).Furthermore, I added support for proper random number generation from within liboqs using the WolfSSL interface. Before, random data is either obtained from OpenSSL, from
/dev/urandom, or using theget_entropy()method, depending on the build configuration of liboqs. With the proposed changes, we use theOQS_randombytes_custom_algorithm()interface to provide a custom RNG method for liboqs. Using a custom method, we can obtain RNG data from WolfSSL. I further added support in different places to use the correct RNG, which is provided in the related context as arguments. In case no RNG is provided by the wrapping context, a new default RNG object is used. As we switch the RNG object to use during runtime, I had to protect the interface with a mutex.I placed the new liboqs related code in new header and source files, which are located in the new
wolfCrypt/port/liboqsdirectory. The files are added both to the Make and CMake build infrastructure. However, I'm not sure if this is the right place for these files, to be honest.I look forward to your feedback!
Kind regards,
Tobi