tls-cipher schemes for control channel negotiation request and certificate read issue about pqcrypto-vpn HOT 38 CLOSED

Hi Alex,

Thanks for your interest!

The current release of PQCrypto-VPN has only been tested against the OQS fork of OpenSSL 1.0.2. In fact there is a particular commit our build scripts sync to that we tested with. We have not tested against the 1.1 fork and so don't know if it will work. That being said, for TLS 1.2 on the control connection, tls-cipher is the OpenVPN configuration directive we used to select the relevant PQ ciphersuites, and guarantee that non-PQ ciphersuites would not be selected. For example, this is the precise directive I use in an internal deployment I have:
tls-cipher OQSKEX-SIDH-MSR-ECDHE-RSA-AES256-GCM-SHA384:OQSKEX-LWE-FRODO-RECOMMENDED-ECDHE-RSA-AES256-GCM-SHA384
This prefers the hybridized-with-ECDHE versions of SIDH first and then Frodo, using RSA certificates for authentication.

The OpenSSL 1.1 branch supports TLS 1.3, and because of the way ciphersuites changed in TLS 1.3, we have run into some problems. Key exchange and authentication algorithms are no longer specified as part of the ciphersuite, and so tls-cipher will no longer work. If you have our code building against the OpenSSL 1.1 branch, you may be running into OpenSSL trying to negotiate a TLS 1.3 session which will not end up using a PQ key exchange algorithm. You may be able to force it to use TLS 1.2 by specifying the --tls-version-max 1.2 configuration directive to OpenVPN and then use tls-cipher like above, but I can't predict if this will work since the 1.1 fork is a significant diversion from the 1.0.2 fork we originally built on. You may need to dig into the source code for the version of OQS-OpenSSL you're building against to look up the TLS 1.2 ciphersuite names that use PQ key exchange algorithms. For best results, I suggest building with the 1.0.2 fork from the commit referenced in our build scripts. If you get a connection going, you will need to closely review the log output from OpenVPN to make sure you are actually using a post-quantum key exchange, and not being defaulted back to a classical algorithm.

We currently have work underway to update PQCrypto-VPN both to the latest version of OpenVPN, and also to make it compatible with OpenSSL 1.1 and TLS 1.3. Our next release will support both.

Now about your certificate question: The errors you describe sound like the wrong Extended Key Usage OIDs being set in the certificates. If you look in our instructions for setting up a Picnic PKI, under the "Create a server certificate" section there is an example extensions file which you can use to tell OpenSSL which EKUs to apply to each certificate. Server certificates have to have the serverAuth EKU and client certificates have to have the clientAuth EKU. If these aren't correct, you'll see certificate validation errors like the ones you've noted. You can feed a certificate to the OpenSSL command line utility with openssl -in cert.cer -noout -text where cert.cer is the name of the server certificate, and in the list of X509v3 extensions you should see a section like this:

            X509v3 Extended Key Usage:
                TLS Web Server Authentication

And similarly "TLS Web Client Authentication" for a client certificate. If these aren't present, or if the wrong type is applied (the client EKU on what should be your server's certificate, for example), that would cause those errors.

As an aside, we discovered after we released that sometimes Picnic certificates can grow too large and trigger a bug that causes the TLS session negotiation to fail. Oops! Also, Picnic was the only working PQ signature algorithm in the OpenSSL 1.0.2 fork we use at the time, so it's the only algorithm we've attempted to use. For this reason we're currently using RSA certificates for authentication. Since the pressing need now is to protect the key exchange from future quantum attacks, you can still get some benefit even without a PQ-signed certificate for authentication. Our next release should have this working correctly, and also be able to use the wider variety of PQ signature algorithms that have been added to OQS-OpenSSL since. I suggest you start with RSA certificates (and make sure you apply the correct EKUs!) to get your setup running, and once it is, then you can experiment with certificates signed with PQ signature algorithms.

Please let me know if you have any further questions.

from pqcrypto-vpn.

Hello Kevin,

Thank you for your response and all this information, I truly appreciate it.

Well the funny part is that just after my initial message and a system reboot I made, I finally managed to have the PQ algorithms ciphers available to my openvpn install on both windows and linux, so now the openvpn process recognizes them and they show up at the --show-tls ovpn directive.

I set it to use tls version 1.2 as you stated and will keep on testing. The problem now is with openssl, it seems it can't handle the picnicl1fs public keys. It seems that i generate them correctly but openvpn server can't verify them:

Dec 10 09:22:21 scw-cool-borg openvpn[13597]: Tue Dec 10 09:22:21 2019 us=597807 OpenSSL: error:0609E09C:digital envelope routines:PKEY_SET_TYPE:unsupported algorithm
Dec 10 09:22:21 scw-cool-borg openvpn[13597]: Tue Dec 10 09:22:21 2019 us=597908 OpenSSL: error:0B07706F:x509 certificate routines:X509_PUBKEY_get:unsupported algorithm
Dec 10 09:22:21 scw-cool-borg openvpn[13597]: Tue Dec 10 09:22:21 2019 us=597982 OpenSSL: error:140BF10C:SSL routines:SSL_SET_CERT:x509 lib

Also I get the following openssl issues:

1. the genoqs command is not resolved
2. can't apply sha512 digest to the certificates when the public/private keys are on pq algorithms like picnicl1fs and dilithium4

Any more recommendations?

Thanks again for your time so far.

from pqcrypto-vpn.

Kevin,

Just a quick update.
I finally managed to run everything correctly on both server and client side and now I am connected to my PQ-VPN. It's exciting!!

I have to report that I managed to do that only on RSA CA, server and client certificate combinations.

I will keep on testing this on other platforms aswell with various possible authentication combinations and protocols, according to all your recommendations.

Thank you again for your time and information so far. Keep up with it guys, the community needs it.

Best regards,
Alex

from pqcrypto-vpn.

I believe the commands for generating OQS PQ key pairs changed in the 1.1 fork, and our instructions are strictly for the 1.0.2 fork. I haven't yet researched how to generate certificates using the 1.1 fork but it should definitely be possible. If you figure it out, by all means please update our instructions and make a pull request.

Make sure your openvpn binary is linking to the OQS-enabled version of OpenSSL instead of the system-installed default. This can be a problem on Linux if you're not careful. Our build scripts set an rpath that should point to versions of OpenSSL installed alongside OpenVPN, but you may want to use ldd to make sure the loader will load those versions rather than the system's default.

Did you verify in your log files that the negotiated ciphersuite is one using a PQ key exchange algorithm once the tunnel is up and running?

from pqcrypto-vpn.

Thanks again for the reply,

Yes I confirm I am on the hybrid version of the PQ kex algorithms as you mentioned before. I am pretty sure it works since I always double check the outputs, check if my IP address changed etc. Also I use the tunnel for DNS, which also works perfect.

Concerning the linking to the openssl, here is my openvpn --version output

openvpn --version
liboqs 1.0.0 [git:notices/65fd62a9e8038cf2] x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD] built on Jul 24 2018
library versions: OpenSSL 1.0.2m-dev xx XXX xxxx, LZO 2.10

My server system normally uses the openssl installed from the fork, no other versions are installed. (So by openssl'ing anywhere in the system i can produce pq keys etc.) Thanks for clarifying about the genoqs command, because I was wondering why it was not recognized. So now I have made it up to here will step into the picnic pk testing according to the instructions you provided. I will be more than happy if I manage to setup this specific PKI.

from pqcrypto-vpn.

You appear to actually be using the 1.0.2 fork of OpenSSL. That version should support the genoqs command in our current documentation.

from pqcrypto-vpn.

I think that my actual openssl is 1.1.1d, but the libraries the openvpn reads from are the original (fork ones)

OpenSSL 1.1.1d 10 Sep 2019
built on: Tue Dec 10 08:31:41 2019 UTC
platform: linux-x86_64
options: bn(64,64) rc4(8x,int) des(int) idea(int) blowfish(ptr)
compiler: gcc -fPIC -pthread -m64 -Ioqs/include -Wa,--noexecstack -Wall -O3 -DOPENSSL_USE_NODELETE -DL_ENDIAN -DOPENSSL_PIC -DOPENSSL_CPUID_OBJ -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DKECCAK1600_ASM -DRC4_ASM -DMD5_ASM -DVPAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DX25519_ASM -DPOLY1305_ASM -DNDEBUG
OPENSSLDIR: "/usr/local/ssl"
ENGINESDIR: "/usr/local/lib/engines-1.1"
Seeding source: os-specific

from pqcrypto-vpn.

In that case, it's also likely the algorithms themselves have changed between the two versions, and so a certificate generated with the 1.1 fork would not be usable with the 1.0 fork.

from pqcrypto-vpn.

That is right, for now though I confirm that I can work (at least) with RSA certificates.

from pqcrypto-vpn.

I also confirm that *PQ-ALGORITHMS-ECDHE-ECDSA are working with ECDSA signed certs.

from pqcrypto-vpn.

I successfully managed to set the according openssl version of the guide (1.0.2) to my server and now genoqs works but when everything is done, it stacks in the handshake with excessive message size error. But maybe that is due my system's default openssl (1.1.1d) gonna check it

from pqcrypto-vpn.

The excessive message size error is also what I observed, and I think that may just be broken, unfortunately. Until a cryptographically-relevant quantum computer exists, though, we can still safely rely on RSA and ECDSA certificates for authentication, and then you get the PQ-protected key exchange you want now.

from pqcrypto-vpn.

I also managed to create Picnic PKI (CA certificate of the Picnic type) and this works if you sign your server and client rsa (and possibly ecdsa also) certificates with that CA.

from pqcrypto-vpn.

This suggests validating the certificate chain isn't a problem, but rather something in validating the signature in the ServerKeyExchange message is generating this error, because the Picnic signature in there is too large, which you'll only get if the end-entity certificate has a Picnic public key.

from pqcrypto-vpn.

Finally I managed to run PQ-only TLS (Control Channel) negotiation. That happened by using Picnic CA and server certificates and a RSA client certificate signed with Picnic CA. It is also possible this can happen with ECDSA client certificate.

from pqcrypto-vpn.

Very interesting. That does narrow down where the problematic section might be. Thanks for spending the time to track down the exact circumstances that cause the failure.

If you find that there is an easy place in the code where we can increase a constant or the size of a buffer to make this work, please consider making a pull request.

from pqcrypto-vpn.

Greetings again,
It's been a while since I started using and testing the PQCrypto-VPN and it seems great. The only bad point is that it works only in hybrid mode (OQSKEX - RSA)
It seems that the broken part has to do with openssl's built-in constants / static files, since the error it provides has to do with the TLS negotiation (routines:ssl3_get_message:execssive) and especially the ssl3.h file seems to do this job.

It would be of great help if there are any clues on which file(s) should be changed in order to build the source manually with the right values. I will have the look at the source of PQCrypto-VPN myself and if I figure it out I will make a statement. Also I would like to ask if there is a ready (built or source) version of PQCrypto-VPN at your end which can be used for the testing of the three major PQ-only setups that can negotiate with no buffer error.

Thanks again for your time and help so far.

Warm regards

from pqcrypto-vpn.

Unfortunately we don't have a version without this bug, which ends up being triggered by most Picnic certificates. Our plan is to update PQCrypto-VPN to use the latest fork of the Open Quantum Safe project's OpenSSL 1.1 fork, as that will contain the latest versions of all the supported algorithms as well as support for TLS 1.3, when that fork is ready. Our resources are focused on doing that, and so we haven't attempted to figure out where we could patch the current version to work around this problem.

I expect the problem is actually in OpenSSL, and not in PQCrypto-VPN, wherever that length exceeded error is generated, but I don't know that for certain. I don't believe OQS has any plans to go back and patch the 1.0.2 branch to work around this problem, and so for these reasons our plan is simply to do a new release with the updated versions of OQS-OpenSSL and OpenVPN.

If you investigate and discover a quick change can fix this problem, please do let me know and we can look at ways to incorporate it. It just becomes complicated if it requires changes to a repo we depend on but don't have any control over.

from pqcrypto-vpn.

Kevin,
Yes updating to openssl 1.1(.1d) would be a great supply because it seems that this last branch has the required fixes on this issue, which also occured in normal older openvpn setups with large-size certificates in the past. It clearly has to do with the built-in openssl configuration used by that setup, and I believe the root of the problem lies within the source of the ssl3.h file which carries the code handling the buffer limits.

Anyway I will be waiting for the updated versions indeed, since I am a fan of PQCrypto since I found it. It would be great if there are other implementations of PQCrypto for other platforms as well (for example Android devices). I have seen that at the moment raspberry is supported. I will be checking the git on regular basis to be sure I am always up to date on it.

Thank you a lot for the time you spent guiding me around and for informing.

Closing this for now but if anything occurs I will get back with a new ticket, pull req. e.t.c.

Best regards

from pqcrypto-vpn.

@pqfan I've got a candidate of the 1.3 release ready for you to try out, in the dev-1.3 branch: https://github.com/microsoft/PQCrypto-VPN/tree/dev-1.3

I've moved to using submodules for the various dependencies, so clone with: git clone --branch dev-1.3 --recurse-submodules https://github.com/microsoft/PQCrypto-VPN.git. There's also a Dockerfile under openvpn/build/docker as well. The Windows build is now done completely cross-compiled, so everything gets built in one step now.

Feedback welcome!

from pqcrypto-vpn.

from pqcrypto-vpn.

from pqcrypto-vpn.

Please note that you do need to update your configuration files to enforce TLS 1.3 on the control channel; in particular, tls-cipher is no longer relevant because support for PQ algorithms has been removed from TLS 1.2 and below. Instead you add tls-version-min 1.3 to guarantee TLS 1.3, and somewhat unintuitively specify a key exchange algorithm with ecdh-curve like ecdh-curve sikep434. Take a look at the updated configuration files in openvpn/config.

The signature algorithm depends on whatever certificate you provide for authentication, and you'll need to regenerate any certificates as the schemes have changed. But in good news, Picnic certificates do now work!

After I did this, I did get a PQ-protected tunnel from my Windows test system. Can you describe in detail the steps you used to build that resulted in the normal version of OpenVPN?

from pqcrypto-vpn.

from pqcrypto-vpn.

How strange!

Would you upload the Windows and Linux installers you built as a reply to this issue, so I can take a look at them?

from pqcrypto-vpn.

https://drive.google.com/open?id=1Qvc5s6H4vanomynd6sQZUPzXMQVjpg4S
https://drive.google.com/open?id=16E3rTDOMt8sOPN3nCHyLl5ut_7FB7s_K

from pqcrypto-vpn.

At first glance I don't see any problems with these binaries. The libraries appear to have the OQS code built in, and I could use both to generate a Picnic signing key, at the very least. What are you seeing that makes you think the OQS code isn't present?

from pqcrypto-vpn.

The --show-tls output does not provide any OQS key exchange mechanisms at all, I get a normal openvpn 2.4.8 --show-tls output.

from pqcrypto-vpn.

Neither using the Linux binary I can run OQS KEMs in a Linux machine, but I will recheck that now

from pqcrypto-vpn.

I understand. There's a critical change here to be aware of: the Open Quantum Safe's fork of OpenSSL 1.1.1 only supports post-quantum algorithms in TLS 1.3. All support for PQ in TLS 1.2 and before has been removed.

In TLS 1.3, the definition of a ciphersuite changed significantly: it no longer specifies the key exchange algorithm or the authentication algorithm, only the symmetric encryption and hash algorithms. This is why the post-quantum key exchange algorithms in TLS 1.3 are masquerading as elliptic curves, and are specified with the ecdh-curve configuration directive.

If you look at the top of the output of openvpn --show-tls, there's a section for TLS 1.3, and there you won't see mention of any of the asymmetric algorithms there, post-quantum or otherwise. And as OQS removed support for TLS 1.2 in this fork, they're all absent from the list of ciphersuites for TLS 1.2.

Right now, it's not obvious from the log output that a PQ key exchange algorithm is being used when OpenVPN starts up. I need to look at adding some logging to include this information. At present I have to verify it's happening by taking a packet capture, and examining the TLS 1.3 handshake, but that's not suitable in general. Similarly, as long as you provide client and server certificates that are using a post-quantum signature algorithm, that algorithm will be used to verify the signatures.

So I think you are able to bring up a completely post-quantum tunnel with the binaries you've built. You just need to make sure your configuration file has been correctly updated. See my previous comments, and the updated examples in openvpn/config.

from pqcrypto-vpn.

Great and thanks for explaining, going to check right now and will get back to you to let you know of the results

from pqcrypto-vpn.

Ok Kevin, the negotiation is being done just fine as you said, apologies for the mistake too, but there is an error with the TAP driver on my windows, it says that it is being used after the negotiation so the connection closes. Any clues on this? Thanks

from pqcrypto-vpn.

I haven't run into this problem before, and I'm not knowledgeable about the TAP driver. I don't think I can help with this.

If you experience the same problem with the official, unmodified version of OpenVPN 2.4.8, so we can be sure our modifications are unrelated, you might try getting advice from the people who maintain it: https://github.com/OpenVPN/tap-windows6

from pqcrypto-vpn.

Kevin,
I can connect to the VPN server, via the gui and ssh, but the traffic seems not to be forwarded correctly, so I can not browse the web through the VPN. I suppose that this is not an error with the DNS proxy because I have set everything regarding the firewall dns accordingly as I did with the previous stable version. The last message of the server log is that of:
MULTI: bad source address from client [::], packet dropped

Any suggestions?

Thank you

from pqcrypto-vpn.

Ok Kevin, I am working smoothly with it now.
I would like to ask you if this current dev version supports all the current liboqs schemes, meaning all the following algorithms found at the liboqs github page:

Supported Algorithms
Key encapsulation mechanisms

BIKE: BIKE1-L1-CPA, BIKE1-L3-CPA, BIKE1-L1-FO, BIKE1-L3-FO
Classic McEliece: Classic-McEliece-348864†, Classic-McEliece-348864f†, Classic-McEliece-460896†, Classic-McEliece-460896f†, Classic-McEliece-6688128†, Classic-McEliece-6688128f†, Classic-McEliece-6960119†, Classic-McEliece-6960119f†, Classic-McEliece-8192128†, Classic-McEliece-8192128f†
FrodoKEM: FrodoKEM-640-AES, FrodoKEM-640-SHAKE, FrodoKEM-976-AES, FrodoKEM-976-SHAKE, FrodoKEM-1344-AES, FrodoKEM-1344-SHAKE
Kyber: Kyber512, Kyber768, Kyber1024, Kyber512-90s, Kyber768-90s, Kyber1024-90s
LEDAcrypt: LEDAcryptKEM-LT12, LEDAcryptKEM-LT32, LEDAcryptKEM-LT52†
NewHope: NewHope-512-CCA, NewHope-1024-CCA
NTRU: NTRU-HPS-2048-509, NTRU-HPS-2048-677, NTRU-HPS-4096-821, NTRU-HRSS-701
SABER: LightSaber-KEM, Saber-KEM, FireSaber-KEM
SIKE: SIDH-p434, SIDH-p503, SIDH-p610, SIDH-p751, SIKE-p434, SIKE-p503, SIKE-p610, SIKE-p751, SIDH-p434-compressed, SIDH-p503-compressed, SIDH-p610-compressed, SIDH-p751-compressed, SIKE-p434-compressed, SIKE-p503-compressed, SIKE-p610-compressed, SIKE-p751-compressed
ThreeBears: BabyBearEphem, BabyBear, MamaBearEphem, MamaBear, PapaBearEphem, PapaBear

Signature schemes

Dilithium: Dilithium2, Dilithium3, Dilithium4
Falcon: Falcon-512, Falcon-1024
MQDSS: MQDSS-31-48, MQDSS-31-64
Picnic: Picnic-L1-FS, Picnic-L1-UR, Picnic-L3-FS, Picnic-L3-UR, Picnic-L5-FS, Picnic-L5-UR, Picnic2-L1-FS, Picnic2-L3-FS, Picnic2-L5-FS
qTesla: qTesla-p-I, qTesla-p-III
Rainbow: Rainbow-Ia-Classic, Rainbow-Ia-Cyclic, Rainbow-Ia-Cyclic-Compressed, Rainbow-IIIc-Classic†, Rainbow-IIIc-Cyclic†, Rainbow-IIIc-Cyclic-Compressed†, Rainbow-Vc-Classic†, Rainbow-Vc-Cyclic†, Rainbow-Vc-Cyclic-Compressed†
SPHINCS+-Haraka: SPHINCS+-Haraka-128f-robust, SPHINCS+-Haraka-128f-simple, SPHINCS+-Haraka-128s-robust, SPHINCS+-Haraka-128s-simple, SPHINCS+-Haraka-192f-robust, SPHINCS+-Haraka-192f-simple, SPHINCS+-Haraka-192s-robust, SPHINCS+-Haraka-192s-simple, SPHINCS+-Haraka-256f-robust, SPHINCS+-Haraka-256f-simple, SPHINCS+-Haraka-256s-robust, SPHINCS+-Haraka-256s-simple
SPHINCS+-SHA256: SPHINCS+-SHA256-128f-robust, SPHINCS+-SHA256-128f-simple, SPHINCS+-SHA256-128s-robust, SPHINCS+-SHA256-128s-simple, SPHINCS+-SHA256-192f-robust, SPHINCS+-SHA256-192f-simple, SPHINCS+-SHA256-192s-robust, SPHINCS+-SHA256-192s-simple, SPHINCS+-SHA256-256f-robust, SPHINCS+-SHA256-256f-simple, SPHINCS+-SHA256-256s-robust, SPHINCS+-SHA256-256s-simple
SPHINCS+-SHAKE256: SPHINCS+-SHAKE256-128f-robust, SPHINCS+-SHAKE256-128f-simple, SPHINCS+-SHAKE256-128s-robust, SPHINCS+-SHAKE256-128s-simple, SPHINCS+-SHAKE256-192f-robust, SPHINCS+-SHAKE256-192f-simple, SPHINCS+-SHAKE256-192s-robust, SPHINCS+-SHAKE256-192s-simple, SPHINCS+-SHAKE256-256f-robust, SPHINCS+-SHAKE256-256f-simple, SPHINCS+-SHAKE256-256s-robust, SPHINCS+-SHAKE256-256s-simple

Note that algorithms marked with a dagger (†) have large stack usage and may cause failures when run on threads or in constrained environments.

Thank you!

from pqcrypto-vpn.

I figured out that the actual algorithms supported are the subset of libOQS that is now implementhed into OQS OpenSSL, which means that the current list is initially the following:

Supported Algorithms

If an algorithm is provided by liboqs but is not listed below, it can still be used in the fork through either one of two ways.

Key Exchange

The following quantum-safe algorithms from liboqs are supported (assuming they have been enabled in liboqs):

oqs_kem_default (see here for what this denotes)
BIKE: bike1l1cpa, bike1l3cpa, bike1l1fo, bike1l3fo
FrodoKEM: frodo640aes, frodo640shake, frodo976aes, frodo976shake, frodo1344aes, frodo1344shake
Kyber: kyber512, kyber768, kyber1024
NewHope: newhope512cca, newhope1024cca
NTRU: ntru_hps2048509, ntru_hps2048677, ntru_hps4096821, ntru_hrss701
Saber: lightsaber, saber, firesaber
SIDH and SIKE: sidhp434, sidhp503, sidhp610, sidhp751, sikep434, sikep503, sikep610, sikep751

The following hybrid algorithms are supported only for L1 schemes; they combine an L1 quantum-safe algorithm listed above with ECDH that uses NIST's P256 curve:

p256_<KEX>, where <KEX> is any one of the L1 algorithms listed above.

Authentication

The following digital signature algorithms from liboqs are supported (assuming they have been enabled in liboqs):

oqs_sig_default (see here for what this denotes)
Dilithium: dilithium2, dilithium3, dilithium4 (not currently on Windows)
Picnic: picnicl1fs
qTesla: qteslapi, qteslapiii

The following hybrid algorithms are supported; they combine a quantum-safe algorithm listed above with a traditional digital signature algorithm ( is any one of the algorithms listed above):

if <SIG> has L1 security, then the fork provides the methods rsa3072_<SIG> and p256_<SIG>, which combine <SIG> with RSA3072 and with ECDSA using NIST's P256 curve respectively.
if <SIG> has L3 security, the fork provides the method p384_<SIG>, which combines <SIG> with ECDSA using NIST's P384 curve.
if <SIG> has L5 security, the fork provides the method p521_<SIG>, which combines <SIG> with ECDSA using NIST's P521 curve.

I should note that dlithium signature scheme actually seems to work on Windows, or at least it seems to be working on my build.
It would be great if we experimentally implemented the other algorithms aswell into the PQCrypto development version, such as the ThreeBears, Classic McEliece and so.

Pretty good work Kevin, keep it up, and since things will change soon, after the NIST pq competition evaluation etc. try to always update the used liboqs libraries in every dev/stable version!

from pqcrypto-vpn.

Regarding your networking issues: You will need to do some network setup on the server side to route traffic to the other side, but since I don't know your networking setup I can't help you with this directly. For most people, if your OpenVPN server is a single host with a single IP address, you need to set up the same kind of NAT masquerading you would need to do for a home internet connection. OpenVPN has some documentation to help you get started: https://community.openvpn.net/openvpn/wiki/BridgingAndRouting

Regarding the supported algorithms, we should support whatever algorithms are supported by OQS-OpenSSL, and the keywords you can use with ecdh-curve are from the list you found of its supported algorithms.

As for what's supported, that's up to the OQS team, not us. If you've noticed some schemes work on Windows that they don't think should, please raise an issue on their issue tracker to let them know!

I plan to update and do our formal release when the OQS team next makes stable releases of liboqs and OpenSSL. Beyond that, we'll have to see. We won't be able to constantly update to be in sync with their development branch, but I expect we can update whenever they hit a significant milestone that's both stable and has significant new features added.

from pqcrypto-vpn.

Closing this issue. If you run into further issues or have more questions, feel free to open new issues, or reopen this one with further comments, as appropriate.

from pqcrypto-vpn.