Commit 937880
2025-05-01 16:02:44 Arne: -/-| /dev/null .. PQCryptoOpenVPN.md | |
| @@ 0,0 1,51 @@ | |
| + | # 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](https://de.wikipedia.org/wiki/Perfect_Forward_Secrecy) |
| + | and typically achieved by using finite field Diffie-Hellmann (see also `--dh`) or |
| + | [Elliptic-curve Diffie–Hellman](https://en.wikipedia.org/wiki/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](https://datatracker.ietf.org/doc/draft-ietf-tls-ecdhe-mlkem/) 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: |