Domain 3 · Lesson 3 of 6

Cryptography Fundamentals

Mật mã học Cơ bản

Key Terms

Symmetric Encryption AES ECB CTR GCM Asymmetric Encryption RSA ECC Diffie-Hellman HMAC SHA-256 Salt Birthday Attack Rainbow Table Hybrid Cryptography Shor's Algorithm

Most Common Exam Trap — Memorize This

Asymmetric Encryption Direction

PUBLIC key encrypts (anyone can send encrypted data)

PRIVATE key decrypts (only owner can read it)

Digital Signature Direction

PRIVATE key signs (signer proves identity)

PUBLIC key verifies (anyone can verify the signature)

Symmetric Encryption

Same key is used for both encryption and decryption. Fast for large data — but how do you securely share the key? This is the key distribution problem solved by asymmetric cryptography.

Algorithm	Key Size	Status	Notes
AES	128 / 192 / 256-bit	CURRENT STANDARD	Platform C uses AES-256-CTR for PII field encryption. NIST-approved since 2001.
DES	56-bit	BROKEN (1998)	Cracked in 22 hours by EFF. Never use. Too short a key.
3DES	112 / 168-bit	DEPRECATED 2024	Three rounds of DES. Legacy systems only. NIST retired it.
RC4	Variable	BROKEN	Stream cipher. Multiple biases. Prohibited in TLS since RFC 7465.

AES Modes of Operation

Mode	How It Works	Security	Best For
ECB	Each block encrypted independently with same key	INSECURE — identical plaintext blocks produce identical ciphertext (pattern visible)	Never use for sensitive data. Demo only.
CBC	Each block XOR'd with previous ciphertext block before encryption	Better than ECB — no patterns. Requires padding. Sequential only.	File encryption. Not streaming.
CTR	Encrypts a counter + nonce to produce keystream; XOR with plaintext	Good. Parallelizable. Nonce must be unique per encryption or security breaks.	Platform C PII field encryption. Streaming data.
GCM	CTR mode + GHASH authentication tag	Best — provides BOTH confidentiality AND authenticity (AEAD). Detects tampering.	TLS 1.3, APIs, authenticated encryption.

AES-CTR Nonce Rule: The nonce (number used once) MUST be unique for every single encryption operation using the same key. If the same nonce is reused with the same key, an attacker can XOR two ciphertexts to recover the plaintext. In Platform C, nonces are generated with crypto/rand — never sequential integers or timestamps.

Asymmetric Encryption

Different keys for encryption and decryption — a mathematically related public/private key pair. Solves the key distribution problem. Slower than symmetric — used for key exchange, not bulk data.

Algorithm	Mathematical Basis	Typical Key Size	Primary Use
RSA	Integer factorization of large primes	2048+ bit (minimum)	JWT signing (Platform C), TLS key exchange, digital signatures
ECC (ECDH / ECDSA)	Elliptic curve discrete logarithm	256-bit ≈ RSA-3072 strength	TLS 1.3 key exchange (ECDHE), certificate signing, mobile devices
Diffie-Hellman (DH)	Discrete logarithm over finite fields	2048+ bit	Key AGREEMENT only — enables two parties to derive shared secret without transmitting it

Important: Diffie-Hellman is a key AGREEMENT protocol — it does NOT encrypt data. It allows two parties to agree on a shared secret over an insecure channel. That shared secret is then used as a symmetric key. ECDHE (Ephemeral DH with ECC) provides Perfect Forward Secrecy (PFS) in TLS 1.3.

Hybrid Cryptography — How TLS Actually Works

Client generates session key

→

Encrypt session key with server's PUBLIC key (RSA/ECDH)

→

Server decrypts with PRIVATE key

→

Both use symmetric AES-GCM for all data

Hybrid = asymmetric for key exchange (slow, secure) → symmetric for bulk data (fast). Best of both worlds.

Hashing & Message Integrity

Hash functions are one-way — they produce a fixed-size output (digest) from any input. No key. No decryption. Used for integrity verification, password storage, and digital signatures.

Algorithm	Output Size	Status	Notes
MD5	128-bit	BROKEN	Collision attacks demonstrated 1996. Never use for security. Legacy checksums only.
SHA-1	160-bit	DEPRECATED	Collision demonstrated 2017 (SHAttered attack). Prohibited for digital signatures.
SHA-256	256-bit	CURRENT STANDARD	SHA-2 family. Used in TLS certificates, JWT, code signing. Platform C standard.
SHA-3	Variable (224-512)	CURRENT	Different algorithm family than SHA-2. Alternative if SHA-2 weaknesses found.

HMAC (Keyed Hash)

HMAC = hash(key + message). Requires a shared secret key. Provides:

Integrity — message was not altered
Authenticity — sender has the shared key
NOT confidentiality — message is readable
NOT non-repudiation — shared key means either party could have created it

Password Hashing & Salts

Passwords must NEVER be stored as plain hashes. A salt (random value unique per user) is added before hashing:

Salt defeats rainbow tables (precomputed hash tables)
Each user's salt must be unique
Use bcrypt, Argon2, or scrypt — NOT SHA-256 alone
bcrypt includes salt automatically; work factor is adjustable

Birthday Attack: Finds two inputs that produce the same hash output (collision). The probability of a collision is much higher than intuition suggests — with a 160-bit hash, you only need ~2^80 attempts to find a collision (not 2^160). This is why SHA-1 (160-bit) was broken — 2^80 is feasible with modern computing. SHA-256 requires ~2^128 — infeasible today.

Quantum Computing Threat

Algorithm	Effect on Cryptography	Impact
Shor's Algorithm	Factors large integers and solves discrete logarithm exponentially faster	Breaks RSA, ECC, Diffie-Hellman
Grover's Algorithm	Speeds up brute-force search of symmetric key space by square root	AES-256 effective strength reduced to 128-bit (still secure)

NIST Post-Quantum Cryptography (PQC) standards (2024): CRYSTALS-Kyber (key exchange), CRYSTALS-Dilithium (signatures). These are quantum-resistant replacements for RSA/ECC.

Exam Tips — Cryptography

PRIVATE key signs; PUBLIC key verifies — the most common exam trap. Don't swap them.
PUBLIC key encrypts; PRIVATE key decrypts — for encryption (not signatures).
AES-ECB is insecure: same plaintext block → same ciphertext block. Pattern is visible. Never use ECB for sensitive data.
SHA-1 and MD5 are BROKEN for digital signatures — use SHA-256 or higher.
HMAC provides integrity + authenticity (NOT confidentiality — the message is not encrypted).
DH = key AGREEMENT only — not encryption. It creates a shared secret; you then use that for symmetric encryption.
Salting defeats rainbow tables; each user needs a unique salt. Bcrypt and Argon2 handle this automatically.

FinTech Company X Work Application — Platform C Cryptography Audit

AES-256-CTR nonces: Confirm nonces are generated with crypto/rand per encryption — not sequential integers or timestamps. A nonce sequence collision destroys all security guarantees of CTR mode.
JWT signing algorithm: Confirm JWT signing uses RSA-2048 private key from Vault, NOT HMAC-SHA256 with a shared secret. A shared HMAC key means any service that verifies JWTs could also forge them — eliminating non-repudiation. RSA asymmetric signing ensures only the private key holder (auth service) can sign.
TLS version: Confirm TLS 1.3 is enforced on all public endpoints. TLS 1.3 mandates ECDHE for key exchange (Perfect Forward Secrecy) and removes broken ciphers (RC4, CBC-based suites). TLS 1.0/1.1 must be explicitly disabled.
Password hashing: Confirm customer passwords are hashed with bcrypt (cost factor ≥ 12) or Argon2id — never MD5, SHA-1, or raw SHA-256. bcrypt's work factor can be increased as hardware improves.

Practice Questions

Q1. A system encrypts database fields using AES-256-CTR. A developer reuses the same nonce value for multiple encryption operations because they increment a counter starting from 0 each time the service restarts. What is the security consequence?

A. Nonce reuse in CTR mode allows an attacker to XOR two ciphertexts to recover plaintext — the keystream is effectively revealed

In CTR mode, the keystream is generated by encrypting nonce+counter. If the same nonce is reused with the same key, the same keystream is generated for different plaintexts. An attacker who captures two ciphertexts encrypted with the same keystream can XOR them together, revealing the XOR of the plaintexts — often enough to recover both. The fix: use crypto/rand for every nonce, or use GCM which detects nonce reuse.

Q2. Platform C signs JWTs using RSA. A relying party wants to verify that the token was signed by the Platform C authentication service. Which key does the relying party use?

A. The PUBLIC key — public key verifies a digital signature created by the private key

In digital signatures: the PRIVATE key creates the signature (signs), and the PUBLIC key verifies the signature. The auth service holds the private key (secret) and signs JWTs. Relying parties receive the public key (from the JWKS endpoint) and verify the signature. This allows anyone to verify authenticity without being able to forge tokens (only the private key holder can sign).

Q3. A legacy system uses AES-128-ECB to encrypt customer credit card numbers. A security auditor flags this as a critical vulnerability. What is the specific weakness of ECB mode?

A. AES-ECB produces identical ciphertext blocks for identical plaintext blocks — patterns in the data remain visible in the encrypted output

ECB (Electronic Codebook) encrypts each 128-bit block independently. Two identical plaintext blocks always produce the same ciphertext. This means patterns in data (such as repeated fields, headers, or structured records) are preserved in the ciphertext. The famous example is the "ECB penguin" — an encrypted bitmap image where shapes are still visible. The fix is any mode that introduces chaining or randomness: CBC, CTR, or GCM.

Q4. Platform C uses HMAC-SHA256 to verify the integrity of webhook payloads from lending partners. What security properties does HMAC provide?

A. Integrity (payload was not altered) and Authenticity (sender has the shared HMAC key) — but NOT confidentiality or non-repudiation

HMAC provides integrity (any modification to the payload invalidates the HMAC) and authenticity (only someone with the shared secret key can produce a valid HMAC). It does NOT provide confidentiality — the payload is readable. It does NOT provide non-repudiation — since both parties share the key, either could have created the HMAC, so you cannot prove to a third party which party generated it.

Q5. A CISSP candidate reads that SHA-1 is no longer approved for digital signatures. Why was SHA-1 deprecated?

A. A practical collision attack was demonstrated (SHAttered, 2017) — two different inputs producing the same SHA-1 hash — violating the collision-resistance property required for digital signatures

SHA-1's 160-bit output is vulnerable to birthday attacks requiring ~2^80 operations. In 2017, Google's SHAttered research produced the first practical SHA-1 collision with ~2^63 operations. A collision in a signature hash means an attacker could substitute a fraudulent document with the same hash as a legitimate signed document. SHA-256 (256-bit output, ~2^128 collision resistance) is the minimum for new applications.

← Lesson 02: Security Models Lesson 04: PKI & Key Mgmt →