End-to-End Post-Quantum Security in ALightVPN

From the moment you provision your configuration file to the moment you connect, ALightVPN now provides complete post-quantum protection.

Get started! https://vpn.alightservices.com

 I thank Microsoft for Startup Founders, Corporate Vision Magazine, Government of U.K, Perplexity, NASSCOM 10000, my parents, my elder sister.

I am are thrilled to announce a major milestone in my commitment to future-proof security: end-to-end post-quantum cryptography (PQC). With my latest update, I have extended post-quantum protection beyond the VPN connection itself to include the highly sensitive provisioning and downloading of your OpenVPN (.ovpn) configuration files.

Using new Windows tool, ALightVPN, users now benefit from an unbroken chain of post-quantum security.

The Vulnerability of Provisioning

The industry focus on post-quantum cryptography has largely centered on the connection phase—encrypting data as it travels between your device and the VPN server. While this is crucial, it leaves a glaring vulnerability: how do you securely transmit the cryptographic keys and certificates to the client device in the first place?

If an adversary with "Store Now, Decrypt Later" (SNDL) capabilities captures the initial download of your .ovpn configuration file—which contains your private keys, certificates, and TLS-auth credentials—they can eventually decrypt that file using a quantum computer. Once they have the keys from the configuration file, the post-quantum security of the actual VPN becomes irrelevant.

I recognized that true post-quantum security must start before the connection is ever made.

ALightVPN: Secure Provisioning

To solve this, I developed ALightVPN, a dedicated Windows client that facilitates the secure provisioning of your VPN profile. Here's how the new end-to-end flow works:

1. API Key Generation: Using the ALightVPN helper, you generate a local ML-KEM keypair. The public key must be submitted in web portal.
2. Encrypted Payload: Server generates your unique API key and encrypts it using your ML-KEM public key combined with AES-256-GCM. This key must be imported either from file or from clipboard.
3. Secure Download via ALightVPN: When you use ALightVPN to request your .ovpn profile, the application uses this post-quantum secured API key to authenticate and establish a secure channel to download the configuration file. You can revoke and get a new ovpn file whenever you want using the ALightVPN.exe tool

This ensures that the .ovpn file—and all the sensitive cryptographic material it contains—is never transmitted over a channel vulnerable to future quantum decryption.

NIST Security Levels: A Tailored Approach

You might notice that I have employed different levels of cryptographic strength for different parts of infrastructure. Specifically, I use NIST Level 5 for profile downloading and API key provisioning, while we use NIST Level 3 for the active VPN connection. This is a deliberate, highly optimized design choice.

What are NIST Security Levels?

The National Institute of Standards and Technology (NIST) defines security categories for post-quantum algorithms based on the difficulty of breaking them compared to traditional symmetric encryption:

• Level 1: As hard to break as AES-128 (exhaustive key search)
• Level 3: As hard to break as AES-192
• Level 5: As hard to break as AES-256

Why NIST Level 5 for Downloading?

We use ML-KEM-1024 (NIST Level 5) for the API key encapsulation and the secure download channel within ALightVPN.

The reasoning: The provisioning phase involves transmitting long-term, high-value static credentials (the API keys and the certificates within the .ovpn file). These credentials form the root of trust for your VPN access. Because this action occurs infrequently (only when setting up a new device or rotating keys) and involves relatively small amounts of data, the slight computational overhead and larger key sizes of ML-KEM-1024 are negligible.

By using Level 5, we apply the absolute maximum available post-quantum security to protect the foundational secrets of your identity.

Why NIST Level 3 for the VPN Connection?

For the active OpenVPN connection, we use SecP256r1MLKEM768 (NIST Level 3 hybrid) within TLS 1.3 control channel.

The reasoning: A VPN tunnel requires a delicate balance between robust security and high performance. The control channel must frequently renegotiate ephemeral session keys to provide perfect forward secrecy. ML-KEM-768 (Level 3) is equivalent in strength to AES-192—which is already vastly beyond what is necessary to secure data for the foreseeable future—while offering significantly smaller public keys and faster encapsulation/decapsulation times compared to ML-KEM-1024.

This optimization is critical for minimizing latency, reducing bandwidth overhead during handshakes, and ensuring a seamless, high-speed browsing experience on mobile devices and variable networks, all without compromising practical post-quantum security.

Conclusion

Security is a chain, and it is only as strong as its weakest link. By securing the provisioning pipeline with ALightVPN and NIST Level 5 cryptography, we have eliminated the vulnerability of SNDL attacks against configuration files.

ALightVPN now offers true end-to-end post-quantum protection: uncompromising Level 5 security for the secrets that identify you, and highly optimized Level 3 security for the high-speed data that connects you.

The ALightVPN.exe tool and the updated post-quantum infrastructure are available now to all users.