search

open-quantum-safe / openssl

UNSUPPORTED Fork of OpenSSL 1.1.1 that includes prototype quantum-resistant algorithms and ciphersuites based on liboqs PLEASE SWITCH TO OQS-Provider for OpenSSL 3
https://openquantumsafe.org/
Other
294 stars 126 forks source link

How can I add a new implementation of one signature schme and run it with openssl? #339

Closed herfrain closed 2 years ago

herfrain commented 2 years ago

I think I have succeeded building a new implementation of dilithium2(with arm_neon) in liboqs by changing some configurations, but I don't know how to use it in openssl, beacuse openssl does not have a algorithm name called "dilithium2_arm".

By the way, I see there are "dilithium2_ref" and "dilithium2_avx2" in liboqs, when we run apps/openssl req -x509 -new -newkey <SIG> -keyout <SIG>_CA.key -out <SIG>_CA.crt -nodes -subj "/CN=oqstest CA" -days 365 -config apps/openssl.cnf If <SIG> is dilithium2, which one will be used, is "dilithium2_ref" default? Then, how can we use "dilithium2_avx2"?

In short, my purpose is to add "dilithium2_arm" and use it in openssl command.

Thanks very much if you can help~

baentsch commented 2 years ago

openssl does not have a algorithm name called "dilithium2_arm".

This is intentional: The name selects the algorithm, not a specific platform code base.

If is dilithium2, which one will be used, is "dilithium2_ref" default? Then, how can we use "dilithium2_avx2"?

This is the right question: At the core of liboqs is the desire to always make available the most suitable implementation for a specific platform. Accordingly, AVX2 will be used if liboqs (and openssl) get built on a(n x86_64) platform supporting that CPU feature (or if it has been specifically requested at build time by configuration).

I think I have succeeded building a new implementation of dilithium2(with arm_neon) in liboqs by changing some configurations

That is very good and it would be great for everyone if you'd consider contributing that to liboqs via a PR: It then would flow automatically into the downstream projects like oqs-openssl (and get automatically used when openssl is built on such platform).

As there currently already is activity in the liboqs project to bring in ARM optimized code (see for example https://github.com/open-quantum-safe/liboqs/pull/1117), your work/contribution there would be great.

herfrain commented 2 years ago

Thanks to your reviewing!

If I understand rightly, after I build an arm implementation of dilithium2 in liboqs and when I run the openssl command with algorithm dilithium2 in ARM platform, then it will automatically use the arm one instead of the ref one?

And of course, I am glad to contribute, but there are many problems have not solved, when I clear them all I will do it, thanks for your invitation.

baentsch commented 2 years ago

If I understand rightly, after I build an arm implementation of dilithium2 in liboqs and when I run the openssl command with algorithm dilithium2 in ARM platform, then it will automatically use the arm one instead of the ref one?

Correct -- if and when there is an ARM-optimized implementation for the specific algorithm available in liboqs (as it is already for Kyber: See for example the code here facilitating that for the decaps operation).

And of course, I am glad to contribute, but there are many problems have not solved, when I clear them all I will do it, thanks for your invitation.

Looking forward to that. OK to close this issue here for now?

herfrain commented 2 years ago

ok~

dstebila commented 2 years ago

Well it is our intention within the next month or so to add the ARM NEON implementation of Dilithium from PQClean (e.g. https://github.com/PQClean/PQClean/tree/master/crypto_sign/dilithium2). How is your implementation different?

herfrain commented 2 years ago

Oh I see, I know Matthias J. Kannwischer’s work, and our work base on his, but we are still working…