Cryptography Essentials

Cryptography is the mathematical foundation of digital trust. You don't need a PhD to use it well — but you do need to know which primitive solves which problem and how to avoid the classic mistakes.

The Three Core Primitives

Symmetric Encryption

One key encrypts and decrypts. Fast and used for almost all bulk data — disks, network streams, databases. The challenge: the sender and receiver need to share the key securely.

Modern best practice: use an authenticated encryption mode like AES-256-GCM or ChaCha20-Poly1305. These give you confidentiality and integrity in one operation. Avoid raw block-cipher modes (ECB, CBC) — they require careful padding and separate authentication, both easy to get wrong.

Asymmetric Encryption

Each party has a key pair: a public key (shared freely) and a private key (kept secret). The pair is mathematically linked so that:

• Anything encrypted with the public key can only be decrypted with the private key
• Anything signed with the private key can be verified with the public key

Asymmetric crypto is slow — typically used only for key exchange and signatures, not bulk data. The two main families:

• RSA — older, well-understood, requires large keys (3072+ bits today)
• Elliptic Curve Cryptography (ECC) — equivalent security at much smaller key sizes (256 bits)

Hashing

A hash function maps any input to a fixed-size output. Properties:

• One-way: infeasible to recover the input from the hash
• Deterministic: same input always produces the same hash
• Collision-resistant: infeasible to find two inputs with the same hash
• Avalanche: tiny input change produces a completely different hash

Two distinct uses, two different best practices:

1. Integrity / fingerprinting: use SHA-256 or SHA-3 — fast and strong.
2. Password storage: use a slow, salted hash designed for passwords — bcrypt, scrypt, or Argon2id. SHA-256 is too fast: a modern GPU can guess billions of common passwords per second against a fast hash.

HMAC and MAC

Plain hashing doesn't authenticate the sender. HMAC mixes a hash with a shared secret so a recipient can verify both integrity and origin. Used heavily in API request signing (e.g., AWS SigV4).

Digital Signatures

A signature proves both authenticity (the document came from the holder of the private key) and integrity (it hasn't been altered). The flow:

1. Hash the document
2. Encrypt the hash with the signer's private key — this is the signature
3. Recipient hashes the document themselves, decrypts the signature with the signer's public key, compares

Digital signatures power code signing, JWTs, container image signing (cosign), and the certificates we'll see next.

TLS: Putting It All Together

TLS (Transport Layer Security, the modern name for SSL) secures essentially every HTTPS connection. A simplified TLS 1.3 handshake:

1. Client says "hello" with the cipher suites it supports.
2. Server responds with its choice + its certificate (containing its public key).
3. Client verifies the certificate against trusted CAs.
4. Client and server perform an Elliptic Curve Diffie-Hellman key exchange to derive a shared symmetric session key.
5. The rest of the connection is encrypted with that symmetric key (AES-GCM or ChaCha20).

TLS uses asymmetric crypto exactly long enough to agree on a symmetric key, then uses the symmetric key for speed. This is the standard pattern for any session-based encryption.

Certificates and PKI

A certificate is a public key, plus identifying information (domain name, organisation), signed by a Certificate Authority (CA). Your browser ships with a list of trusted CAs; if a server's cert chains to one of them, you trust it. This system is called Public Key Infrastructure (PKI).

Common cert types:

• Domain Validated (DV): CA verified you control the domain. Free via Let's Encrypt.
• Organisation Validated (OV) / Extended Validation (EV): CA verifies the organisation. Modern browsers no longer show special UI for EV.
• Wildcard: covers *.example.com.
• Self-signed / private CA: internal use, not trusted by the public web.

Where Things Go Wrong

• Rolling your own crypto. Don't. Use a vetted library (libsodium, BoringSSL) and high-level constructs (NaCl secretbox, age, AWS KMS).
• Hardcoded keys in source code or images.
• Weak algorithms: MD5, SHA-1, RC4, DES. Avoid.
• ECB mode — produces visible patterns in encrypted images. Famous "ECB penguin" example.
• Reusing nonces in stream ciphers — destroys confidentiality.
• Trusting hostnames without certificate validation — a missing TLS verify in code is a one-line MITM vulnerability.

What's Coming: Post-Quantum

Sufficiently powerful quantum computers would break RSA and ECC. NIST has standardised post-quantum algorithms (ML-KEM for key exchange, ML-DSA for signatures). Cloud providers are already rolling them out for TLS — you don't have to act yet, but expect the transition over the rest of the decade.