# pre-shared key control security (tls-crypt/tls-crypt-v2)
-
OpenVPN has two channels for communication - the control channel and the data channel. The control channel is where authentication and key exchanges occur, whereas the data channel transports the encrypted payload. The tls-crypt and tls-crypt-v2 options work by using pre-shared symmetric keys to encrypt the whole control channel and the TLS handshake that occurs there. In essence symmetric keys protect the asymmetric part of the process. Often this kind of protection is called "poor man's post-quantum cryptography".
+
OpenVPN has two channels for communication - the control channel and the data channel. The control channel is where authentication and key agreement occurs, whereas the data channel transports the encrypted payload. The tls-crypt and tls-crypt-v2 options work by using pre-shared symmetric keys to encrypt the whole control channel and the TLS handshake that occurs there. In essence symmetric keys protect the asymmetric part of the process. Often this kind of protection is called "poor man's post-quantum cryptography".
Quoting the man page:
@@ 22,7 22,7 @@
The key agreement is 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 be done in a way that ensures the common secret is not recoverable later, even if the secrets of the client and/or server are at some point compromised. This principle is called [Perfect Forward Secrecy](https://de.wikipedia.org/wiki/Perfect_Forward_Secrecy) and is typically achieved by using finite field Diffie-Hellman (see also `--dh`) or [Elliptic-curve Diffie–Hellman](https://en.wikipedia.org/wiki/Elliptic-curve_Diffie–Hellman). TLS 1.3 typically uses ECDH with the X25519 curve for the key agreement.
-
Pre-sharing the keys as is done with tls-crypt and tls-crypt-v2 is not perfect forward secrecy, although the key exchange occuring inside of the control channel is. For achieving perfect forward 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.
+
To achieve perfect forward 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:
