Encryption Fundamentals

Encryption keeps secrets secret and detects when someone has tampered with data. The cryptographic primitives are mature and standardised; the way to ruin them is almost always at the application layer — wrong mode of operation, reused nonces, predictable IVs, hand-rolled key derivation.

This page is the working set: which primitive solves which problem, and the operational rules that distinguish "secure" from "looks secure."

Two big families

| | Symmetric | Asymmetric |

|---|---|---|

| **Keys** | One shared secret | Public + private pair |

| **Speed** | Fast (GBs/sec on commodity CPUs) | Slow (KBs/sec for RSA, faster for ECC) |

| **Use** | Bulk data encryption | Key exchange, signatures, identity |

| **Examples** | AES, ChaCha20 | RSA, ECDSA, ECDH |

The standard composition: asymmetric to establish a shared symmetric key; symmetric to encrypt the actual data. TLS, Signal, every secure protocol does this. Asymmetric is too slow for bulk; symmetric needs a shared key, which asymmetric provides.

Symmetric encryption

AEAD ciphers

Modern symmetric encryption is AEAD (Authenticated Encryption with Associated Data). One operation provides confidentiality *and* integrity. Don't use older constructions (CBC mode + separate HMAC) for new code.

The two AEAD primitives that matter:

- **AES-GCM** — AES in Galois/Counter Mode. Hardware-accelerated on every modern CPU (AES-NI, ARM crypto extensions). The default for HTTPS, S3 server-side encryption, etc.

- **ChaCha20-Poly1305** — software-fast (no AES-NI needed), constant-time implementations are easy. Used in TLS 1.3 alongside AES-GCM, default in WireGuard.

For new code: AES-GCM if hardware acceleration is available, ChaCha20-Poly1305 otherwise. Both are excellent.

Key sizes

- **AES-128** — 128-bit key. 2^128 brute force; secure for the foreseeable future against classical attackers.

- **AES-256** — 256-bit key. Quantum-resistant against Grover's algorithm (which halves the effective key length); recommended for long-confidentiality data.

- **ChaCha20** — 256-bit key.

Don't use AES-192. It's a strange middle that exists for historical reasons and isn't widely used; AES-128 or AES-256.

Nonce handling: where everyone trips

AEAD ciphers take a nonce (number used once) per encryption. Reusing a nonce with the same key destroys the security of GCM and CCM specifically. ChaCha20-Poly1305 too.

Three correct nonce strategies:

- **Counter** — start at 0, increment per message. Simple, requires you don't crash and reset.

- **Random** — generate from CSPRNG. 96-bit nonces (GCM standard) are safe up to ~2^32 messages per key under birthday-bound logic.

- **Extended-nonce variants** (XChaCha20-Poly1305, XSalsa20-Poly1305) use 192-bit random nonces; collision probability vanishingly small. Use these when you can't reliably manage counters.

Nonce reuse is the single most common AEAD failure. Use a library that manages nonces correctly; don't hand-roll.

Modes you should not use

- **ECB** — deterministic, leaks structural information. Famous for revealing the Linux penguin in encrypted images.

- **CBC without authentication** — vulnerable to padding oracles; malleable.

- **CTR without authentication** — same; ciphertext can be modified meaningfully.

- **Old hash-based MAC + cipher constructions** — easy to combine wrong (encrypt-then-MAC vs MAC-then-encrypt vs encrypt-and-MAC each have different security properties).

If you find yourself needing one of these, you almost certainly want AEAD instead.

Asymmetric encryption and signatures

RSA

The classic. Encryption / signing in the multiplicative group mod a 2048-bit (or larger) composite number.

- **Key size**: 2048-bit minimum, 3072-bit preferred for new keys. Smaller (1024-bit) is broken.

- **Signature**: RSA-PSS for new signatures (PSS, not the older PKCS#1 v1.5 padding). RSA-PKCS#1 v1.5 verification is needed for legacy compatibility.

- **Encryption**: RSA-OAEP padding. Don't use raw RSA or PKCS#1 v1.5 padding — both have known attacks.

In 2026, RSA persists for compatibility but ECC is preferred for new keys.

Elliptic-curve cryptography (ECC)

Same operations (encryption, signatures, key exchange) over an elliptic curve group. Smaller keys for equivalent security:

- **256-bit ECC** ≈ **3072-bit RSA** in security level.

- **384-bit ECC** ≈ **7680-bit RSA**.

Faster, smaller, lower bandwidth. The default for new asymmetric crypto.

Curves to use:

- **Curve25519** (X25519 for ECDH, Ed25519 for signatures) — modern, fast, well-analysed, no obscure parameters. The right default.

- **NIST P-256 (secp256r1)** — older but ubiquitous; required for some compliance regimes (FIPS).

- **NIST P-384, P-521** — for higher security levels.

Avoid:

- **P-224, P-192, B-163** — too short or deprecated.

- **secp256k1** — used by Bitcoin; not the right pick for general crypto (P-256 or Curve25519 instead).

- **Custom curves** — unless you have a specific reason and know what you're doing.

Post-quantum

Shor's algorithm breaks RSA, ECDSA, and ECDH if a sufficiently large quantum computer exists. NIST standardised post-quantum algorithms in 2024:

- **ML-KEM** (Module-Lattice KEM, formerly Kyber) — key encapsulation. Replaces RSA/ECDH for key exchange.

- **ML-DSA** (Module-Lattice DSA, formerly Dilithium) — signatures. Replaces RSA/ECDSA.

For most teams: continue using RSA/ECC; watch for hybrid PQ-classical libraries to mature; plan migration over the next several years. For high-value or long-confidentiality (decades-from-now relevant) data, start adopting hybrid PQ where libraries support it now.

Hash functions

A hash maps arbitrary input to a fixed-length output, ideally with three properties:

- **Pre-image resistance** — given hash `h`, hard to find input `x` with `H(x) = h`.

- **Second pre-image resistance** — given input `x`, hard to find `x' ≠ x` with `H(x) = H(x')`.

- **Collision resistance** — hard to find any `x ≠ x'` with `H(x) = H(x')`.

The collision-resistance bound is roughly half the bit length: SHA-256 has 128-bit collision resistance.

In 2026:

- **SHA-256** — universal default. Hardware-accelerated.

- **SHA-512** — when 256-bit isn't enough; sometimes faster on 64-bit CPUs.

- **SHA-3** (Keccak) — different construction; backup if SHA-2 is ever broken (no signs of that).

- **BLAKE3** — fastest; strong, parallel-friendly. Not yet standardised everywhere but widely deployed.

Avoid: MD5 (broken since 2004), SHA-1 (collisions demonstrated in 2017), SHA-256 truncated to fewer than 128 bits (collision resistance drops below safe threshold).

What hashes are NOT for

- **Password storage.** Use a key derivation function (Argon2id, scrypt, bcrypt). Hashing alone is too fast; brute force is feasible.

- **Encryption.** Hashes are one-way; encryption is reversible. Different problems.

- **Message integrity over a network with an active attacker.** Use HMAC or AEAD. Plain hash + plaintext is vulnerable to length-extension on SHA-2 (use HMAC-SHA-256).

Key derivation

Turn a password or a high-entropy secret into one or more cryptographic keys.

For passwords: **Argon2id**, with appropriate parameters (memory cost, time cost). Parameters tuned to make brute-force expensive while not crippling legitimate logins.

For derivation from already-strong secrets: **HKDF** (HMAC-based Key Derivation Function). Cheap, well-understood, the right choice for "I have a 256-bit secret; I need three 256-bit keys for different purposes."

For older code: PBKDF2 was the standard before Argon2; bcrypt is fine for password hashing if Argon2 isn't available.

Never:

- Use SHA-256 of the password directly. Too fast; brute-force feasible at consumer hardware rates.

- Reuse the master secret as multiple keys. Use HKDF to derive per-purpose keys.

Random number generation

CSPRNG — Cryptographically Secure Pseudo-Random Number Generator. Backed by the OS:

- **`/dev/urandom`** on Linux.

- **`getrandom()`** on modern Linux / glibc.

- **`SecRandomCopyBytes`** on macOS / iOS.

- **`BCryptGenRandom`** on Windows.

Language standard libraries usually wrap these:

- Python: `secrets` module.

- Go: `crypto/rand`.

- Rust: `rand::rngs::OsRng`.

- Java: `SecureRandom` (be careful — older `Random` is not secure).

- JS: `crypto.getRandomValues`.

Never use `rand()`, `Math.random()`, or any non-CSPRNG for cryptographic purposes. They're predictable; they're for simulations and games.

The "don't roll your own" rule

The most often-cited rule in cryptography. It means three different things:

1. **Don't invent your own primitives.** Don't design a new cipher. The state of the art is the result of collective public review by professionals; your hobby cipher will lose.

2. **Don't reimplement existing primitives in production.** Use libraries. Hand-rolled AES will leak side-channel information; the library version is constant-time.

3. **Don't combine primitives in non-standard ways.** Don't invent your own protocol. Use TLS, Signal, age, libsodium constructions. Custom protocols mostly fail to subtle attacks.

What you can do:

- **Use** existing primitives correctly.

- **Compose** them via standardised, well-reviewed protocols.

- **Read** about cryptography to understand what you're using.

Libraries that make doing the right thing easy:

- **libsodium** — Tink, age — high-level APIs that prevent misuse.

- **rustls / BoringSSL / OpenSSL 3.x** — for TLS specifically.

- **Cryptography (Python)** — well-curated set of primitives.

- **Tink (Java/Go/Python/C++)** — Google's misuse-resistant API.

A "what should I use for X" cheat sheet

| Need | Use |

|---|---|

| Encrypt a file with a password | age (`age -p`), or libsodium's `crypto_secretstream` with Argon2id key |

| Encrypt a payload with a known key | AES-GCM or ChaCha20-Poly1305, with a CSPRNG nonce |

| Encrypt for a known recipient | age (`age -r <recipient>`), or libsodium's `crypto_box` |

| Sign data | Ed25519 (`crypto_sign_detached` in libsodium) |

| Authenticate that data hasn't changed | HMAC-SHA-256 |

| Hash a password for storage | Argon2id |

| Generate a session token | 256+ bits from CSPRNG; base64url-encode |

| Hash a file for integrity | SHA-256 or BLAKE3 |

| Establish a shared key over insecure channel | TLS 1.3 if it's a real network; libsodium's `crypto_kx` for in-app |

| Derive multiple keys from a master | HKDF-SHA-256 |