Curve configuration setting

[pqfan]

Greetings Kevin,

Thank you for your working on those latest commits on OQS-OpenSSL and OQS-liboqs because I was stuck for days.

I am trying to figure out if the 0.3.1-dev version of liboqs in combination with openssl-oqs rc2 produce a different curve configuration directive. In dev-3.1 this one is represented within ecdh-curve.

Thank you for your time and work.

Best regards!

[kevinmkane]

I make sure the dev-1.3 branch always builds before I update it, so you should always be able to git submodule update to get back to known good points, if you're experimenting with newer version of the dependencies on your own.

We'll make our next official release (and merge all of these changes to PQCrypto-VPN's master) when OQS declares an official OpenSSL 1.1.1 release.

Are you observing any particular problems with the proper functioning of the ecdh-curve directive with those versions of liboqs and OQS-OpenSSL?

[pqfan]

When I attempt to build with liboqs 0.3.1-dev and openssl-oqs-rc2 the produced windows and linux binaries include the original crypto libraries, meaning that the ecdh-curve setting does not recognize OQS options such as sikep610 or sidhp610 etc. so when a negotiation is started it turns back to classic curves such as secp or sect. In this case the size of the binaries is almost same as the original one (~8,7MB for the windows binary or something like that). If I cmbine liboqs 0.3.0 and openssl-oqs-rc2 then the binaries have sizes similar to the working oqs binaries but again the ecdh-curve setting turns back to classic curves.

I wish my statements give you a directing point for your next commits on the OQS projects.

Best regards

[pqfan]

Kevin I think that I found out the answer, it seems that

ecdh-curve

changes to

group

from now on, but please have a look at it

[pqfan]

Kevin,

Also "remote-cert-ku serverAuth" seems to be more sufficient that "remote-cert-tls server" when creating the certs in Windows

[kevinmkane]

The ecdh-curve is an OpenVPN configuration directive as of version 2.4.9; changes in liboqs or OQS-OpenSSL cannot have changed this. This is still the correct directive to use to choose an PQ key exchange algorithm for OpenVPN.

Have you observed any problems when using the liboqs 0.3.0 and OQS-OpenSSL-rc1 where dev-1.3 currently is?

As for the problems with getting OpenVPN to link against the correct OpenSSL binaries, that's always a tricky business, especially if you're doing builds by hand instead of using our build.py script. If you are doing builds by hand, make sure you're including the command line arguments to point the compiler and linker at wherever you've installed OQS-OpenSSL's include and library paths. Our build.py script is still doing this correctly the last I checked on both Linux and Windows; please forward a bug report with a repro if you're seeing otherwise.

For this upcoming release, I expect we'll stick with liboqs 0.3.0. The only thing that would change this is if liboqs 0.3.1 is released before OQS-OpenSSL 1.1.1, and the latter depends on the former.

[pqfan]

dev-3.1 latest works perfectly as expected, with ecdh-curve recognizing the OQS KEMs etc. dev-3.1 with custom "injected" liboqs 0.3.1-dev and rc2 has issues with ecdh-curve, which recognizes only classical curves etc. but works when group directive is used. Normally group seems to be Linux-only directive but on my build it works with Windows 10 aswell. But probably all this is due to the library linking mismatch you mentioned.

[pqfan]

Here is the actual OpenVPN error:

Mon Jun 29 21:24:03 2020 Failed to use supplied curve (ntru_hps4096821), using secp384r1 instead.
Mon Jun 29 21:24:03 2020 ECDH curve secp384r1 added

[kevinmkane]

We've found the change between RC1 and RC2 broke our curve-setting code. I'll have a fix on the way soon as part of updating the dev-1.3 branch.

[pqfan]

That's great Kevin, I always want to build the pretty latest version of the OQS OpenVPN engine, that's why I run these custom tests. Another issue is that if you build liboqs 0.3.1-dev with rc2 a normal/original OpenVPN is produced (a binary of about 8,5MB or so)

Have a look at this too, when you have some available time.

Thanks for all this work again

[kevinmkane]

I won't be able to look at 0.3.1-dev at this time. We're only going to be looking at the current released version of liboqs once the OQS-OpenSSL 1.1.1 release is official.

That being said, the size of the openvpn binary shouldn't vary noticeably in size if it's accidentally linked against the wrong version of OpenSSL, because all of the OQS code is in the dynamically-linked OpenSSL binaries. The size of the openvpn binary is not a reliable indicator of correct linking. What will change is the size of libcrypto.so.1.1 (on Linux) or libcrypto-1_1-x64.dll (on Windows) compared to normal OpenSSL. An easy check is to search the libcrypto binary for the string "OQS". That doesn't appear in stock OpenSSL.

Please note that if you want to use a pure PQ scheme like ntru_hps4096821, you must specify the ecdh-curve directive in both the server and client configurations. Otherwise, OQS-OpenSSL will only offer the hybrid (classical + PQ) schemes in the ClientHello, and if the server is configured to only accept a pure PQ scheme, they will fail to agree on a key exchange algorithm and fail to connect.

The dev-1.3 branch has now been updated to use liboqs 0.3.0 and OQS-OpenSSL 1.1.1-rc2.