Part 1: Public Key Cryptography
Part 2: Hash functions
Part 3: Integrity Mechanisms
Part 4: Diffie-Hellman
Part 5: Putting It All Together
Part 6: Quantum Attacks and Post-Quantum Cryptography

Up to this point, we have studied the main building blocks: public key algorithms, hash functions, integrity mechanisms, and key exchange. Each addresses part of the security problem. This section shows how they are combined into real systems that provide confidentiality, integrity, and authenticity.

Hybrid Cryptosystems

Public key algorithms solve the problem of exchanging secrets, but they are not suited to encrypting large amounts of data. Symmetric algorithms are efficient at bulk encryption but require a shared key. Modern secure systems combine the two: public key cryptography is used only to establish or protect a symmetric session key, and the session key is then used with a symmetric cipher such as AES or ChaCha20 to encrypt data.

This design is called a hybrid cryptosystem. It combines the strengths of both approaches: public key methods for secure key exchange and symmetric methods for fast, large-scale encryption.

Long-Term and Ephemeral Keys

When public key algorithms are used in practice, they involve different categories of keys with distinct lifetimes and purposes.

• Long-term keys are intended to last months or years. A server, for example, may keep an RSA or ECC key pair that identifies it and is certified by a certificate authority. These keys are reused across many sessions and are tied to the party’s identity.

• Ephemeral keys are very short-term asymmetric keys used only during protocol setup or key exchange. In Diffie-Hellman, for example, each party generates a fresh random private exponent every time they run the protocol. Once the handshake is complete, these temporary keys are erased.

• Session keys are short-lived symmetric keys used for the actual communication within one session. After the handshake creates them, they protect the confidentiality and integrity of data until the session ends, at which point they are discarded.

Long-term keys establish who you are talking to. Ephemeral keys make sure that each run of a key exchange produces fresh material. Session keys are used to encrypt and authenticate all messages within a session.

Forward Secrecy

Forward secrecy is the property that protects past sessions if a long-term key is compromised in the future. Without forward secrecy, anyone who records encrypted traffic today and later obtains the server’s private key could go back and decrypt all those sessions.

With forward secrecy, each session has a unique session key derived from ephemeral Diffie-Hellman. Even if the long-term key leaks, old session keys cannot be reconstructed.

For example, in Diffie-Hellman, each side generates a new ephemeral private value for every session. The shared secret depends on those temporary values, and once they are discarded, there is no way to reconstruct the session key later.

Forward secrecy is one of the strongest arguments for using Diffie-Hellman (or elliptic-curve Diffie-Hellman) instead of simply encrypting a session key with a server’s RSA or ECC public key. Diffie–Hellman makes generating fresh session keys inexpensive, while creating new RSA or ECC key pairs for every session would be too costly.

With forward secrecy, only active sessions are at risk if a key is stolen. Old sessions remain protected because their keys depended on short-lived secrets that no longer exist.

Digital Certificates

Even with hybrid cryptography, one critical problem remains: how do you know you are really talking to the right party? An attacker could pose as a server and perform a man-in-the-middle attack. To prevent this, we need a way to bind public keys to identities.

A digital certificate associates a public key with an identity, such as a domain name or an organization. The most widely used format is the X.509 version 3 (X.509v3) certificate, which is part of the international ITU-T X.500 directory standards.

Certificates are issued by trusted organizations called certificate authorities (CAs). An X.509v3 certificate typically contains:

• Subject: the identity the certificate represents (for example, www.example.com).
• Public key: the subject’s public key.
• Issuer: the certificate authority that issued the certificate.
• Validity period: the start and end dates when the certificate is valid.
• Extensions: extra data, such as constraints on how the certificate may be used.
• Signature: the CA’s digital signature over the certificate contents.

A CA uses its own private key to sign certificates and vouches that the binding between the subject and the public key is valid. Certificates are verified by building a chain of trust back to a root certificate that is already trusted by the operating system or browser.

Root certificates are self-signed and distributed with operating systems, browsers, and mobile devices. Windows, macOS, iOS, Android, and Linux all maintain their own trusted root stores. If a certificate can be chained back to one of these roots, it is accepted as valid.

Certificates solve the problem of authenticating public keys. Once a certificate is verified, the public key inside it can be trusted for secure communications.

When your browser connects to a secure website, the server presents its X.509v3 certificate. The browser verifies the certificate’s signature using the CA’s public key, which is stored in the browser’s trust store. If the certificate is valid, the browser knows it has the correct public key for the server’s identity.

Root Certificates and Trust Stores

Certificates are only useful if we can trust the issuer. At the top of the trust hierarchy are root certificates. A root certificate is a self-signed X.509v3 certificate belonging to a certificate authority (CA). Operating systems and browsers maintain a built-in list of trusted root certificates. This list is called a trust store.

• macOS and iOS: The trust store is managed by Apple’s Keychain system. It contains a set of Apple-approved root certificates that applications can use.
• Windows: The trust store is managed by the Windows Certificate Manager. Microsoft distributes updates to the list of trusted CAs through Windows Update.
• Android: Each device includes a system trust store. Manufacturers and carriers may customize it, but Google maintains the default list. Users can also add their own root certificates.
• Linux: Most distributions rely on the Mozilla CA list and store trusted roots in /etc/ssl/certs or equivalent paths. Applications such as Firefox and Chrome may use their own bundled lists.

The trust store is the anchor: any certificate chain must lead back to one of the trusted roots in order to be accepted.

How a Client Verifies a Certificate

When a client connects to a server over TLS (for example, visiting a secure website), it performs a series of steps to decide whether to trust the server’s certificate:

1. Receive the server’s certificate. The server presents its X.509v3 certificate, and often an intermediate certificate chain, during the TLS handshake.
2. Check validity period. The client ensures that the current date falls within the certificate’s “not before” and “not after” fields.
3. Build the certificate chain. The client follows the chain of issuers until it reaches a self-signed root certificate.
4. Verify signatures. At each step, the client uses the issuer’s public key to verify the signature on the child certificate. A broken signature invalidates the chain.
5. Check against the trust store. The client ensures that the root certificate is in its trust store. If the root is not trusted, the entire chain is rejected.
6. Confirm domain name. The client compares the domain it is connecting to against the subject name or subject alternative name in the certificate. A mismatch means the certificate does not belong to that server.
7. Check revocation status. Clients may consult Certificate Revocation Lists (CRLs) or use the Online Certificate Status Protocol (OCSP) to see if the certificate has been revoked before its expiration date.
8. Verify possession of the private key. The server must prove it controls the private key corresponding to the certificate’s public key. During the TLS handshake, it does so by signing handshake data with its private key. The client verifies this signature with the certificate’s public key. This step prevents attackers from reusing someone else’s certificate without having the key.

If all of these checks succeed, the client accepts the certificate and proceeds with the key exchange. If any check fails, the client presents an error and usually aborts the connection.

How Protocols Use These Pieces

TLS (Transport Layer Security)

TLS, which secures most web traffic, is a classic hybrid cryptosystem:

1. The server presents its digital certificate.
2. The client verifies the certificate with a trusted CA.
3. The client and server perform a key exchange, typically elliptic-curve Diffie–Hellman with ephemeral keys, to agree on a session key.
4. The session key is used with a symmetric cipher such as AES-GCM or ChaCha20-Poly1305 to protect data.
5. Integrity is built into the authenticated encryption mode, which also authenticates associated data such as headers.

This design provides authentication through certificates, forward secrecy through ephemeral key exchange, and efficiency through symmetric encryption.

PGP (Pretty Good Privacy)

PGP applies the same hybrid approach for secure email. The sender generates a random session key, uses it with a symmetric cipher to encrypt the message, and then encrypts the session key with the recipient’s public key. The encrypted session key and ciphertext are sent together. PGP users exchange long-term public keys directly, without relying on certificate authorities. Digital signatures are often added to provide authenticity.

All of the elements come together in real systems:

• Public key cryptography provides secure key exchange and digital signatures.
• Hash functions provide compact fingerprints of data.
• MACs and AEAD modes provide integrity in symmetric settings.
• Digital signatures and certificates provide authenticity and bind public keys to identities.
• Ephemeral keys ensure that each session has unique material, and forward secrecy protects past sessions even if long-term keys are later compromised.
• Symmetric encryption provides efficient protection of the actual data.
  This combination is the architecture of modern cryptography: hybrid systems where each primitive plays the role it is best suited for.

Next: Part 6: Quantum Attacks and Post-Quantum Cryptography