Post-quantum cryptography security in OpenVPN

In general symmetric ciphers (AES-GCM, Chacha20-Poly1305) that are used for data-channel encryption are still safe to use in post-quantum cryptogrpahy. No change is necessary in this area.

The cryptographic algorithm that are affected are the assymetric algorithms that in use. There are three major aspects of post-quantum security in OpenVPN that this article discusses:

  1. pre-shared key control security (tls-crypt/tls-crypt-v2)
  2. post-quantum key agreement
  3. post-quantum signing/certificates

pre-shared key control security (tls-crypt/tls-crypt-v2)

tls-crypt and tls-crypt-v2 work by protecting the whole control channel and the TLS handshake inside control channel with a pre-shared key. Often this kind of protection is called "poor man's post quantum cryptogrpahy".

Quoting the man page:

provides "poor-man's" post-quantum security, against attackers
who will never know the pre-shared key (i.e. no forward secrecy).

Post-quantum key agreement

The key agreement is the what TLS server and client use to agree on a common secret that will be used to derive all encryption keys for the connection. Typically this should done in a way that the common secret is not recoverable later, even if the secrets of the client and/or server are at some point compromised. This priniciple is called Perfect Forward Secrecy and typically achieved by using finite field Diffie-Hellmann (see also --dh) or Elliptic-curve Diffie–Hellman. TLS 1.3 typically use the ECDH with the X25519 curve for the key agreemnt.

For achieving perfect foward secrecy with post-quantum a hybrid ECDHE-MLKEM Key Agreement is used. Examples are X25519MLKEM768, SecP256r1MLKEM768, and SecP384r1MLKEM1024. Typically X25519MLKEM768 is used.

OpenVPN version 2.7.0 and newer will display the key agreement in use during connection:

Control Channel: TLSv1.3, cipher TLSv1.3 TLS_AES_256_GCM_SHA384, [...], key agreement: X25519MLKEM768

The allowed key-agreement can be configured using the --tls-groups configuration options. E.g. using

tls-groups X25519MLKEM768

will only connection that use this post-quantum safe key-agreement. A connection that cannot fulfil this will fail similar to this:

OpenSSL: error:0A000065:SSL routines::no suitable key share:
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9