Cryptography (Symmetric/Asymmetric, Hashing, PKI, TLS 1.3 & Post-Quantum)
In-depth cryptographic foundations for CompTIA Security+, CISSP, and CEH: symmetric block/stream ciphers, modes of operation, asymmetric algorithms, PFS, cryptographic hashing, key stretching, PKI hierarchy, X.509 validation, TLS 1.3 handshake, HSM/TPM hardware roots of trust, and NIST Post-Quantum Cryptography.
- Level
- basic
- Languages
- en → en
- Cards
- 32
- Markdown
- Cryptography (Symmetric/Asymmetric, Hashing, PKI, TLS 1.3 & Post-Quantum) (.md)
Flashcards (32)
| # | Front (Term / Question) | Back (Definition / Answer) | Example | Multiple-Choice Options |
|---|---|---|---|---|
| 1 | How does the TLS 1.3 (RFC 8446) handshake achieve 1-RTT connection establishment compared to TLS 1.2's 2-RTT handshake? | In TLS 1.3, the client anticipates key agreement parameters and sends its supported groups and ephemeral Diffie-Hellman `key_share` directly inside the very first `ClientHello` message. The server responds with `ServerHello` (containing its `key_share`), derives the master secret immediately, and sends `{EncryptedExtensions, Certificate, CertificateVerify, Finished}` already encrypted in a single round trip. | ||
| 2 | Why is Electronic Codebook (ECB) block cipher mode insecure, and how do CBC and CTR modes improve upon it? | ECB encrypts each 128-bit plaintext block independently with the same key, so identical plaintext blocks produce identical ciphertext blocks (preserving visual patterns like the ECB Penguin). CBC (Cipher Block Chaining) XORs each plaintext block with the previous ciphertext block (using a random IV for block 1). CTR (Counter) turns a block cipher into a stream cipher by encrypting sequential nonce+counter values and XORing the keystream with plaintext (allowing parallelization). | ||
| 3 | Compare RSA-PSS, ECDSA, and EdDSA (Ed25519) digital signature algorithms. | RSA-PSS: Probabilistic Signature Scheme using RSA keys; large signatures and slower signing, though verification is fast. ECDSA: Elliptic Curve Digital Signature Algorithm; small keys/signatures, but requires a cryptographically secure random nonce `k` per signature—reusing `k` immediately leaks the private key (e.g., Sony PS3 hack). EdDSA (Ed25519): Deterministic nonce generation on Edwards25519 curve, immune to nonce-reuse and side-channel timing leaks. | ||
| 4 | Why are fast cryptographic hashes (like raw SHA-256) unsuitable for password storage, and compare PBKDF2, bcrypt, scrypt, and Argon2id? | GPUs/ASICs can compute billions of raw SHA-256 hashes per second. Key stretching/Password-Based Key Derivation Functions intentionally add tunable work factors: PBKDF2 applies thousands of HMAC iterations (CPU-hard, vulnerable to GPU parallelism); bcrypt uses the Blowfish state setup (`cost` factor, 4KB RAM); scrypt and Argon2id (OWASP #1 recommendation) are memory-hard and CPU-hard, thwarting custom ASICs and GPUs. | ||
| 5 | What is Mutual TLS (mTLS), and where is it commonly deployed? | In standard TLS, only the server presents an X.509 certificate to authenticate itself to the client. In mTLS, the server sends a `CertificateRequest` during the handshake, and the client must also present a valid X.509 certificate and sign a `CertificateVerify` transcript hash with its private key. It is heavily used in Zero Trust microservices (service meshes like Istio), B2B APIs, and IoT device authentication. | ||
| 6 | Compare Homomorphic Encryption, Zero-Knowledge Proofs (ZKPs), and Blockchain/Distributed Ledger consensus. | Homomorphic Encryption allows mathematical computations to be performed directly on ciphertext so the decrypted result matches operating on the plaintext (protecting data 'in use' in untrusted clouds). Zero-Knowledge Proofs (e.g., zk-SNARKs) allow a prover to mathematically convince a verifier that a statement is true (or a secret is known) without revealing any information about the secret itself. | ||
| 7 | Compare AES, ChaCha20, 3DES, and RC4 symmetric ciphers in terms of block vs stream structure, key sizes, and security status. | AES (Rijndael): 128-bit block cipher with 128-, 192-, or 256-bit keys (10, 12, or 14 rounds); current gold standard. ChaCha20: High-speed 256-bit stream cipher (usually paired with Poly1305 MAC); ideal for mobile/CPUs without AES-NI hardware acceleration. 3DES: Legacy 64-bit block cipher vulnerable to Sweet32 birthday attacks; deprecated. RC4: Biased stream cipher; cryptographically broken and prohibited in TLS. | ||
| 8 | How does the Birthday Attack affect hash collision resistance, and compare MD5, SHA-1, SHA-256, and SHA-3? | By the Birthday Paradox, finding a hash collision for an `n`-bit hash requires roughly `2^(n/2)` operations rather than `2^n`. MD5 (128-bit) and SHA-1 (160-bit, SHAttered attack) are broken for collision resistance. SHA-256 (256-bit, Merkle-Damgard construction, 128-bit collision resistance) is widely secure. SHA-3 (Keccak) uses a completely different 'sponge construction' unaffected by length-extension attacks. | ||
| 9 | Walk through the exact steps of creating and verifying a Digital Signature, and explain how it provides Non-Repudiation. | Creation: The sender computes a cryptographic hash of the message and encrypts (signs) that hash using the sender's own Private Key. Verification: The recipient decrypts the signature using the sender's Public Key to recover the hash, independently hashes the received message, and compares the two digests. Because only the sender possesses the private key (and PKI binds identity to that key pair), the sender cannot deny signing (Non-Repudiation). | ||
| 10 | Compare Certificate Revocation Lists (CRLs), OCSP, and OCSP Stapling. | CRL: A downloadable list of revoked certificate serial numbers signed by the CA; high bandwidth overhead and stale between updates. OCSP (Online Certificate Status Protocol): Real-time query by the client's browser to the CA's OCSP responder for a single certificate, but adds latency and exposes client browsing privacy to the CA. OCSP Stapling: The web server periodically fetches a time-stamped, CA-signed OCSP response and 'staples' it directly into the TLS handshake. | ||
| 11 | How do Shor's Algorithm and Grover's Algorithm on a cryptographically relevant quantum computer impact asymmetric and symmetric cryptography? | Shor's Algorithm solves integer factorization and discrete logarithms in polynomial time, completely breaking RSA, Diffie-Hellman, ECDHE, and ECDSA. Grover's Algorithm provides only a quadratic speedup for unstructured search, reducing `n`-bit symmetric key security to `n/2` bits (so AES-256 retains 128-bit quantum security) and `n`-bit hash collision/pre-image strength proportionally (SHA-256 remains secure). | ||
| 12 | Differentiate between Cryptography, Steganography, Obfuscation, and Tokenization. | Cryptography transforms data into unreadable ciphertext using a key (`confidentiality`). Steganography hides the very existence of a message inside a carrier medium (e.g., modifying the Least Significant Bits of an image/audio file). Obfuscation makes code/text difficult for humans to understand without a cryptographic key. Tokenization replaces sensitive data (like a PAN credit card number) with a random lookup token stored in a token vault (no mathematical relationship). | ||
| 13 | How do Diffie-Hellman (DH) and Elliptic Curve Diffie-Hellman Ephemeral (ECDHE) key exchange work, and why are they vulnerable to MitM without authentication? | DH/ECDHE allow two parties to establish a shared secret over an insecure channel (`g^(ab) mod p` or `a*b*G` on an elliptic curve) without transmitting the secret itself. Because classic DH does not authenticate the participants' identities, an active Man-in-the-Middle can establish separate DH keys with each side unless DH parameters are authenticated via digital certificates/signatures. | ||
| 14 | What is the difference between a Salt and a Pepper in password hashing? | A Salt is a unique, cryptographically random value generated per user and stored alongside the password hash in the database to prevent rainbow tables and identical hashes. A Pepper is a high-entropy secret key shared across all passwords (or an HMAC secret) stored separately from the database (e.g., in an HSM or environment vault) so that a SQL injection database dump alone cannot be cracked offline. | ||
| 15 | What is Perfect Forward Secrecy (PFS), and why does static RSA key exchange fail to provide it? | PFS guarantees that if a server's long-term private key is compromised in the future, past recorded encrypted sessions cannot be decrypted. Ephemeral key exchanges (`DHE` or `ECDHE`) generate unique, temporary session keys per connection that are destroyed after the session ends. With static RSA key exchange, an attacker recording traffic can later use the stolen server private key to decrypt all historical sessions. | ||
| 16 | What is Envelope Encryption in cloud Key Management Services (AWS KMS, GCP Cloud KMS, Azure Key Vault)? | Envelope encryption uses a two-tier hierarchy: a Customer Master Key / Key Encryption Key (KEK) never leaves the cloud HSM. To encrypt data, the application requests a unique Data Encryption Key (DEK), encrypts the local data with the plaintext DEK, discards the plaintext DEK from memory, and stores the KEK-encrypted DEK alongside the ciphertext payload. | ||
| 17 | Describe the PKI Certificate Authority (CA) hierarchy: Root CA, Intermediate (Subordinate) CA, and Registration Authority (RA). | Root CA: The ultimate trust anchor with a self-signed certificate; kept offline in an air-gapped HSM to prevent compromise. Intermediate CAs: Signed by the Root CA (or higher intermediates) and kept online to issue end-entity (leaf) certificates; if compromised, only the intermediate is revoked. Registration Authority (RA): Verifies the identity of certificate applicants before instructing the CA to issue a certificate. | ||
| 18 | Compare PEM, DER, PKCS#7 (.p7b), and PKCS#12 (.pfx/.p12) certificate file formats. | PEM (`.pem`, `.crt`, `.key`): Base64-encoded ASCII text with `-----BEGIN...-----` headers; can hold certificates and private keys. DER (`.der`, `.cer`): Binary form of an X.509 certificate (frequently used in Java/Windows). PKCS#7 (`.p7b`): Contains X.509 certificates and certificate chains ONLY (never private keys). PKCS#12 (`.pfx`, `.p12`): Password-encrypted binary archive storing the certificate chain AND the private key together. | ||
| 19 | What fields are inside an X.509 v3 digital certificate, and why is Subject Alternative Name (SAN) required by modern browsers? | Key X.509v3 fields include Version, Serial Number, Signature Algorithm, Issuer DN, Validity Period (Not Before / Not After), Subject DN, Subject Public Key Info, Extensions (Key Usage, Extended Key Usage, SAN, AIA, CRL Distribution Points), and the CA's Signature. Modern browsers deprecate matching domains against the Subject Common Name (CN) and strictly require matching DNS names or IPs in the SAN extension. | ||
| 20 | What is Authenticated Encryption with Associated Data (AEAD), and why is AES-GCM preferred over AES-CBC in TLS 1.3? | AEAD (such as AES-GCM and ChaCha20-Poly1305) simultaneously provides confidentiality and integrity/authenticity in a single cryptographic construct, computing an authentication tag over both the encrypted payload and unencrypted headers (Associated Data). AES-GCM is parallelizable, hardware-accelerated, and immune to padding oracle attacks (such as POODLE and Lucky13) that plagued AES-CBC. | ||
| 21 | Compare Domain Validation (DV), Organization Validation (OV), and Extended Validation (EV) certificates, as well as Wildcard vs SAN (UCC) certificates. | DV: Automated verification of domain control only (e.g., Let's Encrypt ACME HTTP-01/DNS-01 challenge). OV: Verifies domain control plus legal existence of the organization. EV: Strict legal, physical, and operational vetting of the entity. Wildcard (`*.example.com`) secures all single-level subdomains of one domain; SAN/Multi-Domain secures multiple distinct domains/subdomains in one certificate. | ||
| 22 | What are the three core properties of a cryptographic hash function (Pre-image resistance, Second pre-image resistance, and Collision resistance)? | 1. Pre-image resistance (One-wayness): Given hash `h`, it is computationally infeasible to find any input `m` such that `H(m) = h`. 2. Second pre-image resistance: Given a specific input `m1`, it is infeasible to find a different input `m2` where `H(m1) = H(m2)`. 3. Collision resistance: It is infeasible to find any two distinct inputs `m1 != m2` that produce the same hash output. | ||
| 23 | Compare Symmetric and Asymmetric cryptography across key usage, performance, key distribution scalability, and security services. | Symmetric uses a single shared secret key for encryption and decryption; it is 100–1000x faster (suited for bulk data) but requires `N(N-1)/2` keys for `N` parties and out-of-band key exchange, providing Confidentiality (and Integrity/Auth in AEAD). Asymmetric uses mathematically linked Public and Private keys (`2N` keys total); it is computationally slow, solves key distribution, and provides Confidentiality, Authentication, and Non-Repudiation. | ||
| 24 | What is a 'Harvest Now, Decrypt Later' (HNDL) quantum threat, and what are the NIST Post-Quantum Cryptography (PQC) standards (FIPS 203, 204, 205)? | HNDL occurs when adversaries intercept and store encrypted TLS/VPN traffic today to decrypt once quantum computers mature. NIST standardized lattice-based ML-KEM (CRYSTALS-Kyber, FIPS 203) for general key encapsulation, lattice-based ML-DSA (CRYSTALS-Dilithium, FIPS 204) for digital signatures, and stateless hash-based SLH-DSA (SPHINCS+, FIPS 205) for backup signatures. | ||
| 25 | What is Certificate Pinning (and Certificate Transparency / CAA DNS records), and what operational risk does hard pinning introduce? | Certificate Pinning hardcodes a server's expected X.509 certificate or Subject Public Key Info (SPKI) hash inside a client app so rogue CA certificates are rejected, though it risks bricking connectivity during emergency key rotation. DNS CAA (Certification Authority Authorization) records specify which CAs are permitted to issue certs for a domain. Certificate Transparency (CT) logs publicly audit all issued certs to detect rogue issuance. | ||
| 26 | What is a Length Extension Attack, which hash families are vulnerable, and how does HMAC prevent it? | Hash functions based on the Merkle-Damgard construction (MD5, SHA-1, SHA-256) output their internal state as the final digest. If a naive MAC is built as `H(secret || message)`, an attacker knowing `H(secret || message)` and `len(secret)` can append data and compute a valid hash `H(secret || message || padding || extension)` without knowing the secret. HMAC (`H((K ^ opad) || H((K ^ ipad) || m))`) nested hashing completely prevents this. | ||
| 27 | What is the mathematical trapdoor behind RSA versus Elliptic Curve Cryptography (ECC), and how do their key sizes compare for equivalent security? | RSA relies on the computational difficulty of factoring the product of two large prime numbers (`n = p * q`). ECC relies on the Elliptic Curve Discrete Logarithm Problem (ECDLP)—finding scalar `k` given points `P` and `Q = kP` on an elliptic curve. A 256-bit ECC key provides comparable security (~128-bit security level) to a 3072-bit RSA key, requiring far less CPU, memory, and bandwidth. | ||
| 28 | How is a Certificate Signing Request (CSR) generated, and does the private key ever leave the applicant's server? | The applicant first generates an asymmetric key pair locally on their server/HSM. They then create a PKCS#10 CSR containing the Subject Distinguished Name, Subject Alternative Names (SANs), and their Public Key, digitally signed by their own Private Key (as proof of possession). The Private Key NEVER leaves the applicant's system. | ||
| 29 | Compare a Trusted Platform Module (TPM) and a Hardware Security Module (HSM). | TPM: A dedicated cryptoprocessor chip soldered onto a single endpoint's motherboard (or fTPM in CPU firmware) that stores platform integrity measurements (PCRs for Measured/Secure Boot) and disk encryption keys (BitLocker/LUKS). HSM: A high-performance, tamper-resistant/tamper-responsive network appliance or PCIe card (FIPS 140-3 Level 3/4) managing enterprise PKI root keys, TLS termination, and database encryption. | ||
| 30 | What major security improvements did TLS 1.3 introduce over TLS 1.2, and what is the security trade-off of TLS 1.3 0-RTT Resumption? | TLS 1.3 removed all legacy/vulnerable primitives (static RSA key exchange, CBC mode ciphers, RC4, 3DES, MD5, SHA-1, compression, renegotiation), mandating Ephemeral Diffie-Hellman (PFS) and AEAD ciphers (e.g., `TLS_AES_256_GCM_SHA384`), and encrypts all handshake messages after `ServerHello`. TLS 1.3 0-RTT sends application data on the first flight using a Pre-Shared Key (PSK), but 0-RTT data is vulnerable to replay attacks unless idempotent. | ||
| 31 | Explain Full Disk Encryption (FDE / SED) versus File/Folder-Level Encryption and Database Column/Transparent Data Encryption (TDE). | FDE (e.g., BitLocker, FileVault, LUKS) and Self-Encrypting Drives (SEDs) encrypt every sector of a physical drive to protect data at rest if a laptop/drive is physically stolen while powered off; once booted and unlocked, files are accessible in plaintext to the OS. File/Column encryption protects specific sensitive records even while the OS is running. TDE encrypts database files and backups at rest transparently. | ||
| 32 | Why do hybrid cryptosystems (like TLS and PGP) combine asymmetric and symmetric encryption to send an encrypted message? | Asymmetric encryption is too slow and size-constrained for bulk data. In hybrid encryption, the sender generates a random, one-time symmetric session key (Data Encryption Key / DEK), encrypts the large message payload rapidly using AES-GCM with the DEK, and then encrypts (or negotiates) only the small symmetric DEK using the recipient's Public Key. |