Cryptography and Secure Communications
Core rules
- AES-GCM provides confidentiality and integrity in one pass. AES-CBC and CTR provide confidentiality only and need a separate MAC; ECB leaks plaintext structure and should never be used for anything variable.
- Hashing is not encryption. SHA-256 and SHA-3 give integrity, not secrecy. For passwords use a memory-hard, salted KDF: Argon2id, scrypt, bcrypt, or PBKDF2. A raw hash is a breach waiting to happen.
- Digital signatures give authenticity and non-repudiation; they do not hide the message. HMAC gives integrity and authenticity between parties sharing a key.
- IPsec: ESP encrypts and authenticates; AH authenticates only. IKEv2 negotiates the SA. Modern profiles use AES-GCM-256 with ECDH key agreement.
- TLS 1.3 removed RSA key transport and CBC modes, mandates forward secrecy via ECDHE, and offers 0-RTT resumption that carries a replay risk - do not use it for state-changing requests.
- Post-quantum: CNSA 2.0 and NIST standards point to hybrid key exchange (for example X25519 plus ML-KEM) during transition.
Worked example
A team must encrypt database columns so that tampering is also detectable, and the ciphertext must not reveal that two rows share a value. Reasoning: AES-256-GCM gives confidentiality plus an authentication tag, and a per-record nonce ensures identical plaintexts produce different ciphertexts. ECB would produce identical ciphertext blocks for identical plaintext, leaking equality. The nonce must be unique per key; reuse breaks GCM catastrophically.
Traps that cost marks
Choosing ECB under time pressure; using SHA-256 for password storage; asserting TLS 1.3 still supports RSA key exchange; thinking AH encrypts; and confusing a signature with encryption.