The problem authentication solves
Encryption alone is not enough. If you encrypt a message and send it to the wrong recipient, your data is still compromised. Authentication makes sure that before any encrypted session opens, each party can prove their identity. The question is: how do you verify identity over a network that an attacker can observe and manipulate?
Digital certificates and public-key cryptography
In TLS, authentication is performed using digital certificates. A certificate is a document that binds a public key to an identity (typically a domain name) and is signed by a trusted third party called a Certificate Authority (CA). When your browser connects to a website over HTTPS, it checks the server's certificate to confirm that the public key belongs to the real owner of that domain.
The signature on a certificate is created using asymmetric cryptography. The CA holds a private key it uses to sign certificates, and browsers carry a pre-installed list of trusted CA public keys to verify those signatures. No contact with the CA is needed at the moment of connection.
How authentication works in TLS, IPsec, and MACsec
Each protocol handles authentication somewhat differently.
- TLS uses X.509 certificates. The server always presents a certificate to the client. Mutual authentication, where the client also presents a certificate, is optional and common in enterprise and API environments.
- IPsec authenticates peers using IKEv2, which supports both certificates and pre-shared keys (PSKs). Certificates are preferred in large deployments because they scale without requiring a shared secret between every pair of devices.
- MACsec uses a simpler model: devices on a link share a pre-configured Connectivity Association Key (CAK). Authentication consists of each device proving it holds that key through the MACsec Key Agreement (MKA) protocol.
Digital signatures and how they work
A digital signature is created by hashing a message and encrypting the hash with a private key. The recipient decrypts the hash using the corresponding public key, then checks that it matches a fresh hash of the received message. If both hashes match, the message was not altered and it came from someone holding that private key.
The same mechanism allows a CA to sign a certificate: the CA computes a signature over the certificate content using its private key. Any browser can then verify that signature using the CA's well-known public key, without calling the CA at connection time.
The quantum threat to authentication
The digital signatures used in certificates today rely on RSA and ECDSA, both of which can be broken by Shor's algorithm on a sufficiently large quantum computer. A quantum adversary could forge certificates and impersonate any server, even one whose encryption keys are fully quantum-resistant.
Migrating to post-quantum signatures is therefore as critical as migrating key exchange. NIST standardised ML-DSA (previously CRYSTALS-Dilithium) in 2024 as the primary post-quantum signature algorithm. Certificate infrastructure and TLS 1.3 are being updated to support it.
What about QKD?
Quantum Key Distribution (QKD) uses the laws of quantum physics to share a secret key between two parties over a dedicated optical fiber. It is a powerful tool for key exchange in certain scenarios, but it does not address the authentication problem.
QKD can establish a shared secret securely, but it cannot verify identities. It assumes you already know and trust who is at the other end of the fiber. For authentication, digital signatures remain necessary, which is precisely the domain where post-quantum algorithms like ML-DSA apply.