the key concepts, algorithms you’ll meet, common pitfalls, secure defaults, library recommendations, and short code examples. I can’t browse the web right now, so this summary reflects best practices and widely accepted guidance up through mid‑2024.

 

High-level principles

1. Prefer proven primitives and libraries. Don’t roll your own crypto. Use vetted primitives (AES-GCM, ChaCha20-Poly1305, X25519, Ed25519, etc.) and high-level libraries (libsodium, cryptography for Python, OpenSSL/BoringSSL, webcrypto in browsers).

2. Always use authenticated encryption. Encryption without authentication (e.g., AES-CBC without an HMAC) is dangerous. Use AEAD (Authenticated Encryption with Associated Data) like AES‑GCM or ChaCha20‑Poly1305.

3. Secrets management > algorithm choice. Good key management (generation, storage, rotation, least privilege) matters more than picking AES-256 vs AES-128 for most apps.

4. Minimize attack surface. Use TLS for transport, encrypt sensitive fields at rest, and avoid exposing raw cryptographic operations to untrusted inputs.

5. Fail closed, log carefully. On crypto failures, fail securely and avoid logging secrets or raw ciphertext/keys.

---

Core concepts (must-know)

• Symmetric encryption: same key encrypts and decrypts. Fast. Examples: AES (block cipher), ChaCha20 (stream cipher).

• Asymmetric (public-key) crypto: public/private key pairs for encryption or signatures. Examples: RSA, ECC (Curve25519, P-256).

• AEAD: provides confidentiality and integrity (e.g., AES-GCM, ChaCha20‑Poly1305).

• Message Authentication Code (MAC): HMAC-SHA256, etc., provides integrity/authenticity for symmetric keys.

• Digital signatures: verify origin and integrity (RSA-PSS, ECDSA, Ed25519).

• Key agreement (KEX): X25519, ECDH — create shared secret between peers.

• KDFs (Key Derivation Functions): PBKDF2, scrypt, Argon2, HKDF — turn secrets or shared secrets into strong keys.

• Nonces/IVs: must be used correctly (unique, sometimes unpredictable). Reusing a nonce with the same key can catastrophically break security for many algorithms.

• Randomness: Use cryptographically secure RNG (CSPRNG) from OS (e.g., /dev/urandom, getrandom, CryptGenRandom, SecureRandom).

• Entropy & seeding: especially important on embedded systems or early-boot environments.

---

Algorithms and where to use them (practical)

Symmetric

• AES-GCM — AEAD mode; widely supported/hardware-accelerated (AES-NI). Use for at-rest and in-transit when available. Must ensure unique IV/nonce per key.

• ChaCha20-Poly1305 — AEAD; excellent performance on devices without AES acceleration (mobile, IoT). Also avoids some implementation footguns.

• AES-CBC + HMAC — legacy; ok only if implemented correctly (encrypt-then-MAC) and with safe padding-handling. Prefer AEAD instead.

Asymmetric (encryption & key exchange)

• RSA-OAEP — asymmetric encryption; for encrypting small secrets (e.g., keys). Avoid raw RSA/PKCS#1 v1.5 encryption.

• X25519 (Curve25519) — key exchange; preferred for modern elliptic-curve KEX.

• ECDH (P-256 etc.) — interoperable but certain curves have subtle issues; prefer modern curves like X25519 unless you need specific compatibility.

Signatures

• Ed25519 — modern, fast, safer defaults for signatures.

• ECDSA — commonly used, but signature encoding/nonce generation can be tricky.

• RSA-PSS — safer padding for RSA signatures.

KDFs / Password hashing

• HKDF — extract-and-expand KDF for deriving multiple keys from a shared secret.

• PBKDF2 — older, uses many iterations; still used but slower to increase cost.

• scrypt and Argon2 — memory-hard password hashing; prefer Argon2id for new systems.

---

Modes, padding, and nonce rules (short)

• AES-GCM / ChaCha20-Poly1305: AEAD, provide integrity. Nonce reuse = catastrophic. For AES-GCM, 96-bit random or counter nonces recommended; for ChaCha20, 96-bit nonces too (TLS uses 64-bit counters in some combos — be careful).

• CBC: Requires safe padding (PKCS#7) and encrypt-then-MAC (HMAC) to be safe. Beware of padding oracle attacks.

• CTR mode: stream-like; nonce reuse is catastrophic (XOR cancels).

---

Common mistakes and attacks to avoid

• Rolling your own crypto.

• Reusing nonces/IVs with the same key (AES-GCM, ChaCha20).

• Using unauthenticated encryption (confidentiality without integrity).

• Improper random (predictable PRNG or insufficient entropy).

• Insecure key storage (storing keys in source code, logs, or plain files).

• Failure to validate certificates/hostnames in TLS clients.

• Using deprecated primitives (MD5, SHA-1, RC4, DES, 3DES, RSA PKCS#1 v1.5 encryption).

• Timing/padding oracle/side-channel vulnerabilities due to non-constant-time comparisons or leaking error detail.

• Not rotating/expiring keys or failing to provision revocation.

---

Best practices checklist (practical rules)

• Use AEAD (AES-GCM or ChaCha20‑Poly1305).

• Use TLS 1.3 for transport wherever possible.

• Use modern key-exchange: X25519 or ECDHE.

• Use modern signature algorithms: Ed25519 or RSA-PSS (if RSA required).

• Use HKDF to derive separate keys for encryption/MAC from a single secret.

• Generate keys with CSPRNG and use appropriate lengths (AES-128/256, RSA ≥ 2048 — 3072+ recommended for long-term; prefer ECC like X25519).

• Store keys in a KMS or HSM (AWS KMS, Google KMS, Azure Key Vault, HashiCorp Vault, cloud HSMs).

• Use Argon2id for password hashing (set memory/time/parallelism to match threat model).

• Rotate keys regularly and have clear key revocation/rotation processes.

• Make errors generic; never reveal secrets or detailed crypto failures to clients.

• Test crypto code with unit tests and interop tests; fuzz input handling.

---

Implementation & libraries (recommended)

• libsodium (recommended for most apps) — simple high-level API, offers ChaCha20-Poly1305, X25519, Ed25519, secret-key AEADs.

• NaCl / tweetnacl — minimal, safe primitive set.

• OpenSSL / BoringSSL — full-featured; more complexity and footguns if used at low-level. Use high-level APIs where possible.

• python-cryptography (cryptography.io) — modern and safe high-level APIs in Python.

• Web Crypto API — in-browser crypto.

• bower/node: libsodium-wrappers, crypto (Node built-in) — use high-level wrappers.

• Go crypto packages — Go stdlib provides many safe primitives; use crypto/tls, x/crypto for extras.

---

Example snippets (short, practical)

AES‑GCM (Python, using cryptography)

from cryptography.hazmat.primitives.ciphers.aead import AESGCM
import os

key = AESGCM.generate_key(bit_length=256)
aesgcm = AESGCM(key)
nonce = os.urandom(12)  # 96 bits, must be unique per key
plaintext = b"secret data"
aad = b"assoc data"
ciphertext = aesgcm.encrypt(nonce, plaintext, aad)

# decrypt
pt = aesgcm.decrypt(nonce, ciphertext, aad)

ChaCha20‑Poly1305 (libsodium / PyNaCl)

from nacl.secret import aead_chacha20poly1305_ietf_encrypt, aead_chacha20poly1305_ietf_decrypt
import nacl.utils

key = nacl.utils.random(32)
nonce = nacl.utils.random(12)
cipher = aead_chacha20poly1305_ietf_encrypt(b'plaintext', aad=b'header', nonce=nonce, key=key)
# decrypt similarly

X25519 key exchange (Python pseudocode)

from cryptography.hazmat.primitives.asymmetric.x25519 import X25519PrivateKey
# A generates
priv_a = X25519PrivateKey.generate()
pub_a = priv_a.public_key()
# B generates
priv_b = X25519PrivateKey.generate()
pub_b = priv_b.public_key()
# shared secrets
shared_ab = priv_a.exchange(pub_b)
shared_ba = priv_b.exchange(pub_a)
assert shared_ab == shared_ba
# feed to HKDF to produce symmetric key(s)

Password hashing with Argon2 (Python)

from argon2 import PasswordHasher
ph = PasswordHasher(time_cost=3, memory_cost=64*1024, parallelism=2)
hash = ph.hash("correct horse battery staple")
ph.verify(hash, "correct horse battery staple")

---

Key management (practical)

• Never hardcode keys in code or commit keys to version control.

• Use secrets managers/KMS/HSMs for production (rotate keys, audit access).

• Limit key scope & privileges. Use separate keys for encryption and signing.

• Wrap keys: encrypt data keys with master keys (envelope encryption).

• Have a revocation plan and migration path for compromised keys.

---

Certificates & TLS

• Use TLS 1.3; disable TLS 1.0/1.1 and weak cipher suites.

• Validate certificates fully (chain, expiry, hostname).

• Prefer forward secrecy (ECDHE/X25519).

• Keep CA trust stores up-to-date on servers/clients.

• Use short-lived certificates where possible and automate renewal (Let’s Encrypt, ACME).

---

Testing, auditing & compliance

• Static analysis / linters for crypto misuse (some tools exist).

• Fuzzing of parsers and crypto input handling.

• Third-party audits for high-value systems.

• Penetration testing including side-channel and timing checks if applicable.

• Compliance: be aware of local laws (export controls, data protection like GDPR) — KMS + logging helps compliance.

---

Attacks to be aware of

• Padding oracle attacks (CBC + bad padding handling).

• Timing attacks (use constant-time compares for secrets).

• Replay attacks (use nonces, timestamps, or sequence numbers).

• Bleichenbacher / RSA oracle attacks — avoid RSA PKCS#1 v1.5 decryption patterns that leak error types.

• Side-channel leaks from hardware (cache, power analysis) — consider constant-time libs and HSMs for high-risk environments.

---

Migration and interoperability advice

• If supporting older clients, use secure upgrade paths (dual support for modern+legacy with safe fallbacks).

• Plan key migration: support decrypting older ciphertexts or rotate by re-encrypting when feasible.

• Maintain metadata: store algorithm, key ID, nonce/IV, and any AAD with ciphertext so you can evolve formats safely.

---

Short reference: recommended defaults

• Transport: TLS 1.3 with X25519/ECDHE and AEAD ciphers (AES-GCM or ChaCha20-Poly1305).

• At rest: AES‑GCM (256) or ChaCha20‑Poly1305, with envelope encryption using a KMS.

• Signatures: Ed25519 (or RSA-PSS if RSA required).

• Password hashing: Argon2id with tuned parameters.

• KDF: HKDF with SHA-256/512 for protocol-derived keys.

• Randomness: OS CSPRNG (getrandom, /dev/urandom, CryptGenRandom).

---

If you want, I can:

• give a concrete implementation (end‑to‑end) for your stack (Node.js / Python / Go / Java),

• draft a secure envelope encryption design with KMS and data key handling,

• review a short piece of crypto code and point out issues (paste code),

• or produce a checklist tailored to your app (web API, mobile, IoT, etc.).