Cryptography is the mathematical foundation of every security control your organization depends on. TLS secures traffic in transit. PKI underpins certificate trust. Encryption protects data at rest. Key management determines whether those protections hold under adversarial conditions. Security practitioners who lack a working understanding of cryptographic fundamentals make architectural decisions that undermine controls they believe are protecting them — and they often do not discover the failure until a breach investigation.
Symmetric vs Asymmetric Encryption
The fundamental division in cryptography is between symmetric and asymmetric algorithms. Understanding when each applies prevents architectural errors:
Symmetric encryption uses the same key to encrypt and decrypt. AES (Advanced Encryption Standard) is the universal standard. In practice, use AES-256-GCM — 256-bit key (computationally secure against brute force) with Galois/Counter Mode, which provides authenticated encryption. GCM mode simultaneously provides confidentiality and integrity authentication — you cannot tamper with ciphertext without the authentication tag failing. AES-256-GCM is the correct choice for encrypting data at rest, database field encryption, and bulk data transmission.
Symmetric encryption has one fundamental problem: key distribution. If Alice and Bob have never communicated, how do they securely agree on a shared key? They cannot transmit it over an insecure channel because an eavesdropper would capture it.
Asymmetric encryption solves key distribution using mathematically linked key pairs. RSA, Elliptic Curve Cryptography (ECDH, ECDSA), and the new CRYSTALS-Kyber post-quantum algorithm are asymmetric. A public key can be freely distributed; data encrypted with it can only be decrypted with the corresponding private key. In practice, asymmetric encryption is used for key exchange — not for bulk data encryption, because asymmetric operations are 100-1000x slower than symmetric operations.
Modern cryptographic protocols combine both: asymmetric cryptography establishes a shared secret (key exchange), and that shared secret is used as the key for symmetric encryption of the actual data. This is exactly what TLS does.
TLS 1.3 vs TLS 1.2
TLS 1.3 (RFC 8446, published 2018) is a major security improvement over TLS 1.2 and organizations should enforce TLS 1.3 as the minimum version on all external-facing services:
- Forward secrecy is mandatory: TLS 1.3 eliminated cipher suites that do not provide forward secrecy. In TLS 1.2, if an attacker recorded encrypted traffic and later obtained the server private key, they could decrypt all historical sessions. TLS 1.3 uses ephemeral Diffie-Hellman key exchange for every session — each session uses a unique key that is discarded after use, so recording traffic and later compromising the server private key yields nothing.
- Eliminated weak cipher suites: TLS 1.3 dropped RC4, 3DES, MD5, SHA-1, export ciphers, and RSA key exchange. The remaining cipher suites are all authenticated encryption with associated data (AEAD): AES-128-GCM, AES-256-GCM, and ChaCha20-Poly1305.
- Faster handshake: TLS 1.3 reduces handshake latency from 2 round trips to 1. Session resumption with 0-RTT is available for repeat connections (with specific security trade-offs around replay that must be understood).
- Encrypted handshake: The certificate exchange in TLS 1.3 is encrypted, whereas TLS 1.2 sent certificates in plaintext, allowing network observers to identify which server a client was connecting to.
PKI Architecture
Public Key Infrastructure (PKI) is the trust hierarchy that allows you to verify that a certificate was issued to a legitimate entity by a trusted authority. The chain of trust works as follows:
- Root CA: A self-signed certificate at the top of the trust hierarchy. Root CAs are managed by certificate authorities (DigiCert, Sectigo, Let's Encrypt) and their root certificates are pre-installed in operating system and browser trust stores. Root CA private keys are kept offline in hardware security modules (HSMs) in air-gapped facilities — they sign almost nothing directly.
- Intermediate CA: Root CAs sign intermediate CA certificates, which are kept online to issue leaf certificates. If an intermediate CA is compromised, it can be revoked without revoking the root. Most public certificates chain through 1-2 intermediates.
- Leaf Certificate: The end-entity certificate installed on your web server, signed by an intermediate CA, containing your domain name in the Subject Alternative Name field.
Internal PKI (building your own CA hierarchy using Windows AD CS, HashiCorp Vault, or EJBCA) is appropriate for internal services — code signing, internal APIs, device certificates, VPN client certificates. You control the trust anchor and can issue certificates at scale without per-certificate cost. The trade-off is operational overhead: your CA requires the same security rigor as a commercial CA. Internal CAs must be air-gapped when possible, use HSMs for key storage, and have formal certificate policy (CP) and certification practice statement (CPS) documentation.
Certificate Lifecycle Management
The most common certificate management failure is not cryptographic — it is operational. Expired certificates cause outages; unmonitored certificates leave the organization blind to unauthorized issuance.
- Automated renewal with ACME: Let's Encrypt and most commercial CAs now support the ACME protocol (RFC 8555). Tools like
certbot,acme.sh, and Caddy's built-in ACME client automate certificate renewal before expiration. For infrastructure at scale, use HashiCorp Vault's PKI secrets engine with auto-renewal or Venafi for enterprise certificate lifecycle management. - Certificate Transparency (CT) monitoring: All public CAs are required to log issued certificates to CT logs (RFC 9162). Tools like crt.sh and Facebook's Certificate Transparency Monitor allow you to watch for certificates issued for your domains. Unauthorized certificates — indicating either a compromised CA or domain hijacking — appear in CT logs within minutes of issuance.
- OCSP stapling: Configure OCSP stapling on web servers so clients receive a cached proof of certificate validity from the server rather than contacting the CA's OCSP responder. This improves performance and privacy.
FIPS 140-2/3 and Post-Quantum Cryptography
For organizations in regulated environments (FedRAMP, FISMA, certain NYDFS requirements), FIPS 140-2 or 140-3 validated cryptographic modules are required. This mandates using only validated implementations of approved algorithms — not just the algorithm itself, but the specific implementation validation number from the CMVP database. OpenSSL's FIPS provider and AWS/Azure/GCP FIPS endpoints satisfy this for most use cases.
Post-quantum cryptography is no longer a distant concern. In August 2024, NIST published final standards for post-quantum cryptographic algorithms:
- CRYSTALS-Kyber (now ML-KEM, FIPS 203): Key encapsulation mechanism for key exchange. Replaces RSA and ECDH for key establishment.
- CRYSTALS-Dilithium (now ML-DSA, FIPS 204): Digital signature algorithm. Replaces ECDSA and RSA signatures.
- SPHINCS+ (now SLH-DSA, FIPS 205): Hash-based signature algorithm as a conservative alternative.
Organizations handling data that must remain confidential beyond 10 years — government, healthcare records, financial long-term archives — should be planning hybrid classical/post-quantum migrations now. Harvest Now, Decrypt Later (HNDL) attacks mean adversaries are recording today's encrypted traffic to decrypt when quantum computers become capable. The Fortress MSSP vCISO program can develop a cryptographic inventory and migration roadmap for your organization. Contact us to begin.