Post-quantum VPN
SecP384r1MLKEM1024 in ALightVPN: Standards and Implementation
Quick answer
ALightVPN's current release uses SecP384r1MLKEM1024 for hybrid TLS key agreement. This combines P-384 ECDHE with ML-KEM-1024 to establish key material for the OpenVPN control channel. It is a key-agreement group, distinct from the cipher encrypting your traffic or the signature authenticating a certificate.
What the group name tells you
The name identifies two contributions: secp384r1, also called P-384, and ML-KEM-1024. The TLS construction combines their shared secrets. This hybrid approach retains a classical component alongside the post-quantum component rather than treating an algorithm name as a replacement for a complete protocol.
RFC 10024 specifies the group for TLS 1.3. ML-KEM-1024 is the post-quantum component standardized by NIST in FIPS 203. Neither reference is a certificate that an individual VPN session used the intended configuration.
Where it fits in the connection
- Authenticate the peer. The client validates the server's identity using the configured certificate checks.
- Establish key material. TLS negotiates the hybrid group for the OpenVPN control channel.
- Protect the tunnel. OpenVPN uses its control channel to establish data-channel keys; the negotiated data cipher protects tunnel packets.
- Reach the destination. Traffic leaves the VPN server toward the destination. HTTPS remains valuable beyond that boundary.
A hybrid exchange does not change every certificate signature into a post-quantum signature. Keep authentication checks enabled and use the supported package and profile together.
Release configuration and connection evidence
| Observation | Meaning | Limit |
|---|---|---|
Current release group: SecP384r1MLKEM1024 | Identifies the intended ALightVPN key agreement. | Does not establish the result for an arbitrary client or profile. |
| TLS minimum 1.3 and a single hybrid group in the release configuration | Expresses the intended TLS policy. | Effective settings can differ across deployments or overrides. |
| Selected group in a successful tunnel handshake | Provides evidence about that connection. | Must be tied to the actual session, client and server. |
The release configuration uses tls-version-min 1.3 and selects SecP384r1MLKEM1024 through tls-groups. Treat a configuration listing as policy evidence; inspect session diagnostics to establish what was negotiated.
Choose a supported path
Start with current official Downloads and retain the package version, platform and profile issue date. Changing the OpenVPN executable or its loaded cryptographic library can change available groups. A successful connection on another configuration is not automatically equivalent.
Follow the session-verification guide and consult client compatibility before replacing dependencies.
Common questions
Is SecP384r1MLKEM1024 the VPN's data cipher?
No. It establishes key material during TLS key agreement. The OpenVPN data channel has its own negotiated cipher.
Does this make certificate authentication post-quantum?
Not by itself. Certificate signatures and identity validation are separate from the hybrid key agreement.
Can the website's TLS test verify my VPN tunnel?
No. A website test examines that HTTPS connection. Check the VPN client's successful tunnel-handshake diagnostics.
Sources and product references
- RFC 10024: hybrid key agreement for TLS 1.3
- NIST FIPS 203: ML-KEM standard and errata
- OpenVPN 2.7 manual: groups, TLS and diagnostics
- Official ALightVPN downloads
Reviewed 2 November 2026. Release configuration and platform availability are distinct from live-session test evidence.