Network Security & Architecture
243 cards · 13 sections
Sections▾
Cryptographic Solutions (OBJ 1.4, 2.3, & 2.4)
Cryptography
The practice of writing and solving codes to hide the true meaning of information.
Encryption
The process of converting ordinary information (plaintext) into an unintelligible format (ciphertext). Only parties with the correct key can reverse the process and read the original data.
Plaintext
Ordinary, readable information before encryption is applied.
Ciphertext
The unintelligible, scrambled output produced by applying an encryption algorithm and key to plaintext.
Cipher
An algorithm that performs an encryption or decryption function. A cipher is a mathematical formula that dictates how data is transformed between plaintext and ciphertext.
Algorithm (Cryptographic)
A mathematical function that takes an input, applies a mathematical transformation using a key, and produces a scrambled output. The same algorithm is used for both encryption and decryption when paired with the correct key.
Key (Cryptographic)
The essential piece of information that determines the output of a cipher. All encryption strength comes from the key, not the algorithm. If the key is compromised, the entire cryptographic system fails regardless of algorithm strength.
Key Length
The size of a cryptographic key measured in bits. Key length is directly proportional to the level of security provided. A 128-bit key is considered secure for most applications; a 256-bit key provides exponentially greater protection — not merely double — because the keyspace grows by squaring the value.
Key Rotation
The practice of regularly changing cryptographic keys to mitigate the risk of unauthorized decryption over time. Best practice for organizations; many rotate TLS keys annually and cloud providers may auto-rotate keys every 90 days.
Security Through Obscurity
The practice of relying on secrecy of design or implementation for security. Considered unreliable and insecure. Modern cryptography relies on open, peer-reviewed algorithms combined with secret keys — not on hiding how the algorithm works.
ROT13 Cipher
A substitution cipher that rotates each letter 13 positions in the alphabet (Rotate 13). Used as a teaching example: the algorithm is the rotation, the key is 13. Adding 13 encrypts; subtracting 13 decrypts.
Encryption protects data in all three states
Encryption can be applied to data at rest, data in transit, and data in use. Each state requires different encryption approaches and tools.
- Data at rest — inactive data on storage devices; protected by full disk, partition, file, volume, database, or record encryption
- Data in transit — data moving across networks or between system components (including RAM-to-processor); protected by TLS, VPNs, IPSec
- Data in use — data undergoing active processing inside the CPU; protected by application-level encryption, access controls, and secure enclaves
Algorithm vs Key — the key provides security, not the algorithm
Almost all modern encryption algorithms have undergone public peer review and are open-source. Their strength derives from rigorous mathematical design that is publicly verifiable, not from secrecy. The confidentiality of encrypted data depends entirely on the secrecy and strength of the key.
- Algorithm = the mathematical formula (public, peer-reviewed, transparent)
- Key = the secret value that determines the cipher's output (must be protected at all costs)
- If the key is compromised, security fails regardless of algorithm robustness
Key strength factors
Two factors determine how resistant a cryptographic implementation is to attack: key length and key rotation.
- Longer keys = exponentially stronger. 128-bit → 256-bit is not 2x stronger; it squares the keyspace, making brute-force attacks exponentially harder
- Regular key rotation limits the window of exposure if a key is eventually compromised. Many organizations rotate Transport Layer Security (TLS) keys annually; cloud providers may auto-rotate every 90 days.
- Technology advances and prolonged exposure weaken even strong keys over time
Key protection requirements
Encryption keys must be safeguarded because they are the single point of failure for the entire cryptographic system.
- Store keys in secure hardware modules (HSM, TPM)
- Encrypt keys when at rest
- Transmit keys securely when in use
- Strictly limit access with regular audits and monitoring for unauthorized access
Section overview — topics to be covered
This section spans objectives 1.4, 2.3, and 2.4 and covers the full cryptographic landscape tested on the exam.
- Symmetric vs asymmetric encryption algorithms
- Symmetric algorithms: DES, 3DES, IDEA, AES, Blowfish, Twofish, RC suite
- Asymmetric algorithms: Diffie-Hellman, RSA, Elliptic Curve Cryptography (ECC)
- Hashing: MD5, SHA family, RIPEMD, HMAC — and hash attacks
- Public Key Infrastructure (PKI) and digital certificates
- Blockchain: public ledger, cryptocurrency, supply chain management
- Encryption tools: TPM, HSM, key management systems, secure enclaves
- Obfuscation: steganography, tokenization, data masking
- Cryptographic attacks: downgrade, collision, birthday, quantum
Primary concept: encryption strength comes from the key, not the algorithm
The exam will test this distinction directly. Scenario: 'What provides the security in an encryption system?' → The key. Scenario: 'An organization uses a well-known open-source algorithm — is this secure?' → Yes, if keys are properly managed. Modern cryptography is open; security through obscurity is not relied upon.
Distinction: encryption vs hashing
Encryption is reversible with the key (plaintext → ciphertext → plaintext). Hashing is one-way (data → fixed-length digest, cannot be reversed). The exam will test this difference. Scenario: 'need to recover original data' → encryption. Scenario: 'need to verify integrity without recovering original' → hashing.
Distinction: cipher vs algorithm vs key
Cipher = the algorithm that performs encryption/decryption. Algorithm = the mathematical formula. Key = the secret value fed into the algorithm. The exam may use these terms interchangeably in questions, but the core concept tested is always: the key is what must be protected.
Scenario: longer key length requested for future-proofing → 256-bit over 128-bit
If the scenario asks which key length provides stronger protection against future threats or quantum computing concerns, 256-bit is exponentially stronger than 128-bit. The increase is not linear — it squares the keyspace.
Scenario: keys have been in use for 2+ years → implement key rotation
If the scenario describes prolonged key exposure or a compliance requirement for periodic key changes, key rotation is the answer. Regular rotation mitigates the risk of unauthorized decryption from long-term exposure.
Primary distinction: security through obscurity is unreliable
The exam explicitly treats security through obscurity as an insecure practice. Scenario: 'Company keeps its encryption algorithm secret instead of using a standard one' → this is security through obscurity and is unreliable. The correct approach is using open, peer-reviewed algorithms with strong, protected keys.
Scenario: encryption keys stored in plaintext on a server → store in HSM or TPM
If the scenario describes keys stored insecurely (plaintext, unprotected file system, shared directory), the correct remediation is to store them in a hardware security module (HSM) or trusted platform module (TPM), encrypted at rest, with strictly limited access.
Symmetric vs Asymmetric Encryption (OBJ 1.4)
Symmetric Encryption
A method of encryption where the same single key is used for both encryption and decryption. Also called private key encryption or private key algorithms. Both sender and receiver must know the same shared secret key.
Asymmetric Encryption
A system of encryption that uses two different keys — one key to encrypt the data and a second key to decrypt the data. Also called public key cryptography. Does not require a shared secret key.
Shared Secret Key
The single key used in symmetric encryption that both the sender and receiver must possess. The same key encrypts and decrypts. Protecting and distributing this shared secret at scale is the primary challenge of symmetric cryptography.
Public Key Cryptography
Another name for asymmetric encryption. Uses a key pair: a public key (can be freely shared) and a private key (kept secret). Eliminates the key distribution problem inherent in symmetric encryption.
Stream Cipher
An encryption algorithm that encrypts data bit by bit or byte by byte in a continuous stream. Uses a keystream generator to create a bitstream mixed with plaintext via an XOR function. Well-suited for real-time communication data streams such as streaming audio or video. Tends to be symmetric and implemented in hardware.
Block Cipher
An encryption algorithm that breaks input into fixed-length blocks (typically 64, 128, or 256 bits) before performing encryption on each block. If the message is smaller than the block size, padding is added. Easier to set up and implement than stream ciphers, less susceptible to security problems, and easily implemented in software.
XOR Function
Exclusive OR — a mathematical function used by stream ciphers to mix the keystream with plaintext to produce ciphertext. The same operation is used for both encryption and decryption when the same keystream is applied.
Hybrid Encryption Approach
A method that combines asymmetric and symmetric encryption to leverage the strengths of both. Asymmetric (public key) encryption is used to securely exchange a shared secret key, which is then used for symmetric encryption of the bulk data transfer. This overcomes the key distribution problem while maintaining the speed advantage of symmetric encryption.
Symmetric encryption — properties and limitations
Symmetric encryption uses one shared key for both encryption and decryption. It provides confidentiality but cannot provide non-repudiation.
- Provides confidentiality — only key holders can access the data
- Cannot provide non-repudiation — anyone with the key could have performed the action; you cannot prove which specific key holder did it
- Key distribution is the primary challenge — as the number of users grows, the number of required key pairs grows rapidly. For N users communicating pairwise, N(N−1)/2 unique keys are needed
- Symmetric algorithms are 100 to 1,000 times faster than equivalently secure asymmetric algorithms
Asymmetric encryption — properties and benefits
Asymmetric encryption uses a key pair (public and private). It solves the key distribution problem and enables non-repudiation through digital signatures.
- Public key is freely shared; private key is kept secret by its owner
- Data encrypted with the public key can only be decrypted with the corresponding private key
- Eliminates the key distribution problem — no shared secret needs to be exchanged beforehand
- Enables non-repudiation when combined with digital signatures (private key signs, public key verifies)
- Common algorithms: Diffie-Hellman, RSA, Elliptic Curve Cryptography (ECC)
Stream cipher vs Block cipher
Ciphers are also categorized by how they process data — one bit/byte at a time (stream) or in fixed-size blocks (block).
- Stream cipher: encrypts bit by bit using a keystream + XOR. Best for real-time audio/video. Typically symmetric and hardware-based.
- Block cipher: encrypts in fixed blocks (64, 128, or 256 bits). Uses padding for undersized blocks. Easier to implement in software. Less susceptible to security problems.
- Most stream ciphers are symmetric; block ciphers can be used in different modes of operation
Hybrid approach — how real-world systems combine both
Most practical cryptographic systems use a hybrid model that combines asymmetric and symmetric encryption for optimal security and performance.
- Step 1: Asymmetric encryption securely exchanges a one-time symmetric session key
- Step 2: Symmetric encryption uses that session key for the bulk data transfer
- Result: solves key distribution (via asymmetric) while maintaining speed (via symmetric)
- This is how TLS/SSL handshakes work in practice
Primary distinction: symmetric uses one key, asymmetric uses two
Scenario: 'encryption method that uses the same key to encrypt and decrypt' → Symmetric. Scenario: 'encryption method that uses a public and private key pair' → Asymmetric. This is the most fundamental distinction tested on the exam.
Scenario: need to prove who sent a message → Asymmetric (digital signatures)
Symmetric encryption cannot provide non-repudiation because multiple parties share the same key. If the scenario requires proving which specific individual performed an action, asymmetric encryption with digital signatures is required.
Scenario: large number of users need to communicate securely → Asymmetric solves key distribution
Symmetric encryption requires N(N−1)/2 unique keys for N users to all communicate pairwise. This becomes unmanageable at scale. Asymmetric encryption eliminates this problem — each user only needs their own key pair.
Scenario: bulk data encryption requiring high speed → Symmetric (after key exchange)
Symmetric encryption is 100–1,000x faster than asymmetric. If the scenario involves encrypting large volumes of data efficiently, symmetric encryption is the answer — typically after using asymmetric encryption for the initial key exchange (hybrid approach).
Scenario: real-time voice or video stream encryption → Stream cipher
Stream ciphers encrypt bit by bit in a continuous stream, making them well-suited for real-time communication data streams like streaming audio or video. Block ciphers process fixed-size blocks and are less suited for continuous real-time streams.
Scenario: software-based encryption implementation → Block cipher
Block ciphers are easily implemented through software solutions, whereas most stream ciphers tend to be used in hardware-based solutions. If the scenario specifies a software implementation, block cipher is the more likely answer.
Distinction: confidentiality vs non-repudiation in symmetric encryption
Symmetric encryption provides confidentiality (only key holders can read the data) but does NOT provide non-repudiation (cannot prove which specific key holder performed an action). The exam may present a scenario where symmetric encryption is used and ask what security property is missing — the answer is non-repudiation.
Primary concept: hybrid approach is how TLS/SSL works
The exam expects you to understand that real-world systems combine both types. Asymmetric encryption handles the key exchange; symmetric encryption handles the bulk data. Scenario: 'How does TLS secure web traffic?' → Hybrid: asymmetric for the handshake/key exchange, symmetric for the session data.
Symmetric Algorithms (OBJ 1.4)
DES — Data Encryption Standard
Symmetric block cipher with a 64-bit key (8 bits used for parity, leaving an effective key length of 56 bits). Processes 64-bit blocks through 16 rounds of transposition and substitution. Used from the 1970s to the early 2000s. Considered weak by modern standards due to the short effective key length.
3DES — Triple DES
Enhanced version of DES using three separate 56-bit keys applied in sequence: encrypt with key 1, decrypt with key 2 (which scrambles further because the key does not match), then encrypt with key 3. Effective key strength of 112 bits.
IDEA — International Data Encryption Algorithm
Symmetric block cipher using 64-bit blocks and a 128-bit key. Widely known for use in PGP (Pretty Good Privacy). Entered the NIST AES replacement contest but did not win.
AES — Advanced Encryption Standard
Also called the Rijndael algorithm or Rijndael cipher after its creator. Symmetric block cipher selected by NIST as the replacement for DES and 3DES. Supports 128, 192, or 256-bit keys. US government standard for sensitive but unclassified information. The de facto standard for symmetric key cryptography.
Blowfish
Symmetric block cipher with a variable key size of 32–448 bits, encrypting 64-bit blocks. Open source and unpatented. Developed as a DES replacement but not widely adopted.
Twofish
Symmetric block cipher with 128-bit blocks, supporting 128, 192, or 256-bit keys. Open source and unpatented. Finalist in the AES contest; lost to Rijndael.
RC Cipher Suite — Rivest Cipher
A family of six symmetric algorithms created by cryptographer Ron Rivest. RC stands for Rivest Cipher. RC1 was never published; RC2 was considered weak; RC3 was cracked before release. RC4, RC5, and RC6 were released and used in networks.
RC4
Symmetric stream cipher with a variable key size of 40–2048 bits. Used in SSL (Secure Socket Layer) and WEP (Wired Equivalent Privacy). The only stream cipher among the commonly discussed symmetric algorithms; all others are block ciphers.
RC5
Symmetric block cipher supporting key sizes up to 2048 bits.
RC6
Symmetric block cipher based on RC5. Stronger and more advanced than RC5. Entered the AES replacement contest as a candidate but lost to Rijndael.
All listed symmetric algorithms are block ciphers except RC4
RC4 is the only stream cipher in this group. All others are block ciphers:
- Stream cipher: RC4
- Block ciphers: DES, 3DES, IDEA, AES, Blowfish, Twofish, RC5, RC6
3DES process — Encrypt-Decrypt-Encrypt with three keys
3DES applies the DES algorithm three times in a specific sequence:
- Step 1: Encrypt plaintext with key 1 using the DES algorithm
- Step 2: Run the DES decryption function with key 2 — key 2 does not decrypt; it scrambles further
- Step 3: Encrypt the output with key 3 using the DES algorithm
- Result: effective key strength of 112 bits from three 56-bit keys
How AES became the standard
NIST held an open contest to replace DES and 3DES. Candidates included IDEA, Twofish, and RC6. The Rijndael cipher won and was standardized as AES. AES is now both the de facto industry standard and the US government standard for sensitive but unclassified data.
Exam focus: symmetric vs asymmetric and block vs stream — not key sizes
Memorizing all block sizes and key sizes is not required for the exam. Focus on: (1) identifying an algorithm as symmetric or asymmetric, (2) identifying it as a block or stream cipher, (3) knowing which is strongest or most widely used.
RC4 is the only stream cipher — all others are block ciphers
Exam lists symmetric algorithms and asks which is a stream cipher -> RC4. All others (DES, 3DES, IDEA, AES, Blowfish, Twofish, RC5, RC6) are block ciphers.
AES -> strongest symmetric algorithm -> US government standard
Scenario asks for the strongest, most widely adopted, or US federal standard symmetric algorithm -> AES. May also appear as Rijndael — both names refer to the same algorithm.
AES = Rijndael — same algorithm, two names
Rijndael was the original contest submission name. AES is the official NIST standard name. The exam may use either. They are the same cipher.
RC4 -> WEP and SSL
Scenario mentions WEP (Wired Equivalent Privacy) or legacy SSL -> the underlying cipher is RC4. Both WEP and SSL are deprecated but appear in exam scenarios testing legacy knowledge.
3DES does NOT encrypt three times — it uses Encrypt-Decrypt-Encrypt
The 3DES sequence is encrypt-decrypt-encrypt across three separate keys. The middle step uses the decryption function with a non-matching key, which scrambles the data further. Effective key strength = 112 bits, not 168.
IDEA -> PGP
Scenario involves PGP (Pretty Good Privacy) and asks which symmetric algorithm it uses -> IDEA. IDEA appears in exam context almost exclusively to test this PGP association.
Primary symmetric standard for the exam -> AES
When a scenario offers multiple symmetric algorithm options and asks which is current, strongest, or federally approved -> AES. DES and 3DES are legacy. IDEA is niche (PGP only). RC4 is deprecated. Blowfish and Twofish are open-source alternatives that lost the AES contest.
Asymmetric Algorithms (OBJ 2.4)
Asymmetric Algorithm (Public Key Cryptography)
Encryption system that uses two mathematically related keys — a public key and a private key — to encrypt and decrypt data. No shared secret key is required between parties.
Public Key
Freely and openly distributed key. Used to encrypt data sent to the key owner, or to verify a digital signature created by the key owner's private key.
Private Key
Secret key known only to its owner. Used to decrypt data encrypted with the matching public key, or to create a digital signature.
Digital Signature
A hash digest of a message encrypted with the sender's private key. Provides integrity (hash detects tampering) and non-repudiation (only the sender holds the private key).
Diffie-Hellman (DH)
Asymmetric key exchange algorithm used to securely distribute symmetric session keys over an untrusted network. Widely used in VPN tunnel establishment via IPSec.
RSA (Rivest-Shamir-Adleman)
Asymmetric algorithm used for key exchange, encryption, and digital signatures. Security relies on the difficulty of factoring large prime numbers; supports key sizes of 1024–4096 bits.
Elliptic Curve Cryptography (ECC)
Asymmetric algorithm based on the algebraic structure of elliptic curves over finite fields. Approximately 6× more efficient than RSA; a 256-bit ECC key equals the security of a 2048-bit RSA key.
ECDH (Elliptic Curve Diffie-Hellman)
ECC variant of the Diffie-Hellman key exchange protocol that provides the same secure key exchange with smaller key sizes.
ECDHE (Elliptic Curve Diffie-Hellman Ephemeral)
ECDH variant that uses a different key for each portion of the key establishment process inside the Diffie-Hellman key exchange.
ECDSA (Elliptic Curve Digital Signature Algorithm)
ECC-based public key algorithm used by the US Government for all digital signature needs.
Four Security Properties of Public Key Cryptography
- Confidentiality — encrypt with receiver's public key; only the receiver can decrypt
- Integrity — hash digest of the message detects any in-transit tampering
- Authentication — verified identity of the key owner through key pair ownership
- Non-repudiation — sender signs with private key; cannot deny authorship
Confidentiality — Encrypt with Receiver's Public Key
To achieve confidentiality, encrypt the message using the receiver's public key. Only the receiver's private key can decrypt it — even the original sender cannot read the data once encrypted (one-way encryption).
Non-repudiation — Sign with Sender's Private Key
To achieve non-repudiation, the sender encrypts the message or hash using their own private key. Anyone can verify using the sender's freely available public key, proving only the sender could have created the signature.
Digital Signature Process — Full Security Stack
- Step 1: Create a hash digest of the message → provides integrity (detects tampering)
- Step 2: Encrypt the hash with the sender's private key → provides non-repudiation
- Step 3: Encrypt the message with the receiver's public key → provides confidentiality
- Result: integrity + non-repudiation + confidentiality + authentication in one flow
ECC Efficiency vs RSA
ECC is approximately 6× more efficient than RSA. A 256-bit ECC key provides equivalent security to a 2048-bit RSA key, requiring less processing power — preferred for mobile devices, tablets, and low-power hardware.
Diffie-Hellman Key Exchange Role
DH is used to securely exchange a symmetric shared secret key before establishing an encrypted tunnel (e.g., IPSec VPN). The asymmetric DH exchange solves the key distribution problem for symmetric algorithms.
Confidentiality vs Non-repudiation — Key Usage Distinction
- Confidentiality → encrypt with the RECEIVER's PUBLIC key (only receiver decrypts)
- Non-repudiation → sign/encrypt with the SENDER's PRIVATE key (proves sender identity)
- Primary distractor: mixing which key and which party applies to each goal
Primary Use: Diffie-Hellman
Scenario: securely exchange symmetric keys over the internet or establish a VPN tunnel → Answer: Diffie-Hellman. DH is asymmetric and is used for key exchange as part of IPSec tunnel establishment.
Diffie-Hellman Vulnerability
Scenario: DH is susceptible to what attack → Answer: on-path (person-in-the-middle) attack. Mitigation: require authentication (password or digital certificate) at the start of the key exchange process.
Primary Use: ECC
Scenario: mobile device, tablet, or low-power device needs asymmetric encryption → Answer: ECC. Primary reason: equivalent security to RSA with smaller key sizes and lower processing cost.
Primary Use: RSA
Scenario: key exchange, encryption, and digital signatures in enterprise → Answer: RSA. Also: physical rotating-code tokens (6-digit code every 30–60 seconds) store RSA asymmetric one-time-use keys for MFA authentication.
Asymmetric vs Symmetric — No Shared Secret
Scenario: algorithm type that does NOT require a pre-shared secret key → Answer: asymmetric (public key cryptography). Primary distractor: symmetric vs asymmetric — symmetric requires a pre-shared key; asymmetric uses a public/private key pair instead.
Hashing (OBJ 1.4)
Hashing
A one-way cryptographic function that takes an input and produces a unique, fixed-length message digest as its output. Cannot be reversed to recover the original input.
Message Digest (Hash Digest)
The fixed-length output produced by a hashing algorithm that acts as a digital fingerprint for the input. Output length is always the same regardless of input size.
Collision
When two different inputs produce the same hash digest output. More likely with shorter hash lengths; MD5 (128-bit) is most susceptible.
MD5 (Message Digest 5)
Hashing algorithm that produces a 128-bit hash value. Widely used historically but prone to collisions due to its limited 128-bit output space; no longer considered secure for integrity verification.
SHA-1 (Secure Hash Algorithm 1)
Produces a 160-bit hash digest. Significantly fewer collisions than MD5 due to larger output space, but now considered deprecated for most security uses.
SHA-2
Family of hash functions with digest sizes of 224, 256, 384, or 512 bits (named accordingly: SHA-224, SHA-256, SHA-384, SHA-512). Uses 64–80 rounds of computation.
SHA-3
Newer SHA family with digest sizes from 224 to 512 bits. Uses 120 rounds of computation — significantly more than SHA-2's 64–80 rounds — providing a major security increase.
RIPEMD (Race Integrity Primitive Evaluation Message Digest)
Open source hashing algorithm available in 160-bit, 256-bit, and 320-bit versions. RIPEMD-160 is the most commonly used variant; created as a competitor to SHA but less widely adopted.
HMAC (Hash-based Message Authentication Code)
Checks the integrity and authenticity of a message by pairing a hashing algorithm with a secret key. Always used in combination: HMAC-MD5, HMAC-SHA1, HMAC-SHA256.
Digital Signature
A hash digest of a file or message encrypted with the sender's private key. Provides integrity (hash detects changes) and non-repudiation (only the sender holds the private key).
Code Signing
Applying a digital signature to a software installer or file. The file is hashed and the hash is encrypted with the developer's private key to verify the file has not been modified since publication.
DSA (Digital Signature Algorithm)
Asymmetric algorithm used exclusively for digital signatures. Relies on a 160-bit message digest; used by the US federal government via the Digital Signature Standard (DSS).
DSS (Digital Signature Standard)
US federal government standard for digital signatures. Relies on a 160-bit message digest produced by DSA.
Three Core Properties of Hashing
- One-way — cannot reverse a hash digest to recover the original input
- Fixed-length output — hash length is determined by the algorithm, not the input size
- Digital fingerprint — any change to input, even one bit, produces a drastically different digest
Hash Length, Collisions, and Algorithm Progression
- MD5: 128-bit output — most collision-prone; no longer secure
- SHA-1: 160-bit output — fewer collisions than MD5; now deprecated
- SHA-2: 224–512-bit output (SHA-224, SHA-256, SHA-384, SHA-512) — 64–80 rounds
- SHA-3: 224–512-bit output — 120 rounds; most secure of the SHA family
Digital Signature Verification Process
- Sender: hash the file → encrypt hash with sender's private key → attach as digital signature
- Receiver: decrypt signature with sender's public key → get original hash digest
- Receiver: independently hash the received file → compare both digests
- Match = file not modified in transit (integrity); encrypted by private key = non-repudiation
HMAC — Integrity Plus Authenticity
Unlike a plain hash (integrity only), HMAC uses a shared secret key alongside the hash algorithm to also verify message authenticity. Always paired: HMAC-MD5, HMAC-SHA1, or HMAC-SHA256.
Code Signing — Digital Signature for Software
The application file is hashed and the hash is encrypted with the developer's registered private key. Verifies the installer has not been modified or corrupted since the developer published it.
Hashing vs Encryption — One-Way Distinction
- Hashing → one-way; cannot reverse the digest to get original data; used for integrity
- Encryption → two-way; can decrypt with the correct key; used for confidentiality
- Primary distractor: confusing hash (integrity) with encryption (confidentiality)
Most Secure Hashing Algorithm
Scenario: most secure hashing algorithm → Answer: SHA-3 (120 rounds) or SHA-256/SHA-512. Primary distractor: SHA-1 is no longer recommended; MD5 is most vulnerable to collisions.
HMAC vs Plain Hash
Scenario: check integrity AND authenticity of a message → Answer: HMAC. Plain hashing provides integrity only; HMAC adds authentication via a shared secret key.
Digital Signature Algorithm — Government vs Commercial
Scenario: US federal government digital signature standard → Answer: DSS (uses DSA, 160-bit digest). Scenario: commercial/enterprise digital signatures → Answer: RSA (faster; also supports encryption and key distribution).
Collision Vulnerability by Algorithm
Scenario: which hashing algorithm is most susceptible to collisions → Answer: MD5 (128-bit). Larger output space = fewer collisions; SHA-256 and SHA-512 are far less susceptible than MD5.
Code Signing Trigger
Scenario: developer publishes app to Google Play or App Store → Answer: code signing. Process: hash the installer → encrypt hash with developer's private key → attach signature to file.
Basics of Increasing Hash Security (OBJ 1.4)
Pass-the-Hash Attack
Hacking technique that allows an attacker to authenticate to a remote server or service using the underlying hash of a user's password instead of the plaintext password. The hash functions as an equivalent to the original password, so the attacker never needs to crack it.
Birthday Attack
Attack where an attacker sends two different messages through a hash algorithm to produce the same hash digest (collision). Exploits the statistical probability of collisions modeled on the birthday paradox.
Birthday Paradox
Statistical principle that with 23 people there is a ~50% chance of two sharing a birthday; with 57 people the probability reaches ~99%. Forms the mathematical basis for the birthday attack against hash collisions.
Collision
Two different inputs that produce the same hash digest output. Collisions reduce hash integrity and are the target of birthday attacks.
Key Stretching
Technique that mitigates a weaker key by running it through an algorithm to create a longer, more secure key, increasing the time and computational cost required to crack it. Used by WPA, WPA2, and PGP.
Salt
Random data added to a password before it undergoes hashing. Ensures that even identical passwords produce different hash outputs.
Salting
Process of adding a salt (random data) to a password before hashing to thwart dictionary attacks, brute force attacks, and rainbow table attacks. Even two users with the same password will produce different hash digests.
Nonce
Number used once; a unique, often random number added to the password-based authentication process to ensure repeated authentication attempts produce different hash outputs. Prevents replay attacks.
Rainbow Table
Pre-computed table used to reverse cryptographic hash functions. Rendered ineffective against salted hashes because each unique salt value forces the attacker to compute an entirely new table.
Mimikatz
Penetration testing tool that automates the process of harvesting password hashes and conducting pass-the-hash attacks against Windows systems.
Pass-the-Hash: How It Works
- Attacker obtains the hash of a user's password via sniffing or credential harvesting
- Hash is reused to authenticate directly against remote systems without knowing the plaintext password
- Windows domain misconfiguration or missing patches enables hash harvesting
- Tools like Mimikatz automate hash harvesting and pass-the-hash execution
Pass-the-Hash: Defenses
- Allow only trusted operating systems to connect to servers
- Ensure Windows domain trusts are configured correctly
- Keep all workstations patched and updated
- Enforce multi-factor authentication (MFA)
- Apply least privilege to all user accounts
Salting Defends Against Three Attack Types
- Dictionary attack: salt alters the hash so predefined word lists fail
- Brute force attack: salt makes every password combination more time-consuming
- Rainbow table attack: salt forces attackers to compute a new table for each salt value
Nonce and Replay Attack Prevention
A nonce adds a transient, unique number to the authentication sequence so the resulting hash changes every transaction. Prevents replay attacks where an attacker resubmits captured authentication data for unauthorized access.
Account Lockout as Password Attack Defense
Limiting failed login attempts (typically three) before locking the account prevents brute force and password cracking attacks against user credentials.
Primary Attack: Authenticate Without Cracking the Hash
Scenario
Attacker authenticates to a remote system using a stolen hash without knowing the plaintext password
Answer
Pass-the-Hash Attack — hash reused directly as authentication credential; no cracking required
Primary Attack: Two Inputs Produce the Same Hash Digest
Scenario
Attacker generates two different messages that produce the same hash value to bypass authentication
Answer
Birthday Attack — exploits hash collision probability; mitigate with longer digests (SHA-256 or higher)
Primary Defense: Prevent Rainbow Table Attacks
Scenario
System needs to ensure pre-computed hash reversal tables are ineffective
Answer
Salting — unique salt per password forces a separate table computation for every salt value
Primary Defense: Prevent Replay Attacks on Authentication
Scenario
Attacker captures and resubmits authentication data to gain unauthorized access
Answer
Nonce (number used once) — ensures repeated authentication attempts produce different hash outputs
Salting vs Nonce: Key Distinction
Salt is added before hashing to ensure identical passwords hash differently (defends against dictionary/brute force/rainbow table). Nonce is added to each authentication transaction to prevent replay attacks.
Key Stretching vs Salting: Key Distinction
Key stretching runs a weak key through an algorithm to make it longer and harder to crack. Salting adds random data to a password so identical passwords produce different hash outputs.
Primary Mitigation: Reduce Birthday Attack Effectiveness
Scenario
Organization wants to reduce hash collision probability in their password storage scheme
Answer
Use longer hash digests — SHA-256 over MD5 significantly reduces the number of possible collisions
Public Key Infrastructure (OBJ 1.4)
PKI (Public Key Infrastructure)
Entire system of hardware, software, policies, procedures, and people based on asymmetric encryption that creates and manages asymmetric key pairs and digital certificates. Encompasses both the encryption process and the full trust management infrastructure.
Certificate Authority (CA)
Trusted third party that issues digital certificates and maintains the level of trust between certificate authorities worldwide. Provides a server's public key to clients establishing a secure connection.
Digital Certificate
Issued by a certificate authority to bind a public key to an entity's identity, enabling clients to trust a server's identity. Retrieved from the CA when a browser initiates an HTTPS connection.
Key Escrow
Process where cryptographic keys are stored in a secure third-party location for retrieval when keys are lost or when required for legal investigations. Ensures encrypted data remains accessible to authorized parties even after key loss.
PKI Five Components
- Hardware — physical devices such as Hardware Security Modules (HSMs) that generate and store private keys securely
- Software — applications that implement PKI functions including CA software and certificate management systems
- Policies — rules governing how certificates are issued, used, renewed, and revoked (e.g., Certificate Policy, CPS)
- Procedures — step-by-step processes for certificate lifecycle management and key handling
- People — administrators, certificate authority operators, and end users who participate in the PKI system
TLS/HTTPS Handshake: Asymmetric to Symmetric
- Client requests the server's public key from the Certificate Authority (CA)
- Client generates a random shared secret key
- Client encrypts the shared secret using the server's public key
- Encrypted shared secret is sent across the internet — only the server can decrypt it
- Server decrypts using its private key; both parties now share the secret
- Symmetric encryption (e.g., AES) creates the TLS/SSL tunnel for all subsequent data
PKI vs Public Key Cryptography
PKI is the complete system for creating, managing, and validating asymmetric key pairs and digital certificates. Public key cryptography refers only to the encryption and decryption process, which is one component of PKI.
Key Escrow: Benefits and Risks
- Benefit: Allows key recovery when an employee leaves or loses their private key
- Benefit: Supports legal investigations requiring decryption of stored data
- Risk: A malicious actor who gains escrow access can decrypt vast amounts of data
- Requirement: Escrow storage must be highly secure with strictly regulated access
PKI vs Public Key Cryptography: Key Distinction
PKI is the complete system (hardware, software, policies, procedures, people) for creating and managing asymmetric key pairs, certificates, and certificate authorities. Public key cryptography is only the asymmetric encryption/decryption process — one component within PKI.
Primary Role: Certificate Authority
Scenario
Browser needs to verify a web server's identity before establishing an HTTPS connection
Answer
Certificate Authority (CA) — issues digital certificates and provides the server's public key to the client
Primary Use Case: Key Escrow
Scenario
Employee unexpectedly leaves and their encrypted files are inaccessible to the organization
Answer
Key Escrow — allows the organization to retrieve encryption keys from a secure third-party location
Most Likely Reason: HTTPS Uses Asymmetric Then Symmetric
Scenario
Why does TLS begin with asymmetric encryption but switch to symmetric for data transfer?
Answer
Asymmetric (PKI) securely exchanges the shared secret key; symmetric (AES) is then used for fast bulk encryption of all session data
Primary Risk: Key Escrow
Scenario
Organization is concerned about the security implications of centralizing encryption keys
Answer
Key escrow creates a high-value target — a single breach exposes all escrowed data; access must be strictly regulated
Digital Certificates (OBJ 1.4)
Digital Certificate
A digitally signed electronic document that binds a public key with a user's identity (person, server, workstation, or device). Uses the X.509 standard within PKI and contains the owner's name, organization, public key, and certificate authority information.
Wildcard Certificate
A digital certificate that allows all sub-domains of a primary domain to share the same public key certificate. Denoted by an asterisk (e.g., *.domain.com covers www.domain.com and courses.domain.com).
Subject Alternate Name (SAN)
A field within a digital certificate that allows a single certificate to cover multiple different domain names that do not share the same root domain. Required when one certificate must cover entirely different domains (e.g., domain1.com and domain2.com).
Single-Sided Certificate
A certificate arrangement where only one party — typically the server — presents a digital certificate to authenticate itself to the client. The client is not required to hold or present its own certificate.
Dual-Sided Certificate
A certificate arrangement where both the server and the client present digital certificates to mutually authenticate each other. Provides stronger security but requires twice the server processing power; used only in high-security environments.
Self-Signed Certificate
A digital certificate signed by the same entity whose identity it certifies, rather than by a trusted Certificate Authority. Provides encryption but no external identity verification; causes browser warnings on publicly-facing websites.
Third-Party Certificate
A digital certificate issued and signed by a trusted Certificate Authority (CA) whose root certificate is embedded in major browsers and operating systems. Its authenticity can be traced back to a known trusted CA, making it inherently trusted by client systems.
Root of Trust (Chain of Trust)
A hierarchical validation model where each certificate's authenticity is validated by the certificate authority that issued it, tracing back through the certification path to a trusted root certificate authority at the top.
Registration Authority (RA)
An entity that accepts digital certificate requests, validates the requester's identifying information, and forwards the validated request to the Certificate Authority (CA) for certificate issuance.
Certificate Signing Request (CSR)
A block of encoded text submitted to a Certificate Authority containing the requesting entity's information (organization name, domain name, locality, country) and public key. The private key associated with the CSR is never sent to the CA.
Certificate Revocation List (CRL)
A complete list maintained by a Certificate Authority of every digital certificate it has ever revoked, typically due to compromise. Browsers and systems check the CRL before trusting a certificate.
OCSP (Online Certificate Status Protocol)
A protocol that allows real-time verification of a single certificate's revocation status using its serial number. Faster than the CRL because it queries one certificate at a time, but does not use encryption.
OCSP Stapling
An extension of OCSP where the certificate holder periodically retrieves the OCSP record and attaches it to the TLS/SSL handshake, eliminating an extra client-to-CA round-trip. Formerly known as the TLS Certificate Status Request Extension.
Public Key Pinning
An HTTPS mechanism where a website presents a set of trusted public keys to the client browser via HTTP headers. If the browser receives a certificate whose public key does not match the pinned set, it alerts the user to a potential impersonation attack.
Key Escrow Agent
A trusted party that holds a secure copy of a user's private key for recovery when the original key is lost. Access must be strictly controlled and requires at least two administrators simultaneously (dual control) to retrieve an escrowed key.
Key Recovery Agent
Specialized software that enables the restoration of lost or corrupted cryptographic keys. Functions as a disaster-recovery backup for the Certificate Authority's key store in the event of a major incident.
Wildcard vs SAN — when to use each
Use a wildcard certificate when all servers share the same root domain. Use a Subject Alternate Name (SAN) when one certificate must cover multiple different root domains.
- Wildcard (*.domain.com) — covers all sub-domains of one root domain; one certificate, one management point
- SAN — required when domains differ at the root level (company1.com and company2.com cannot use a wildcard)
- Wildcard risk: if the certificate is compromised and revoked, all sub-domain servers are affected simultaneously
Certificate revocation methods — CRL vs OCSP vs OCSP Stapling
Three mechanisms for verifying certificate revocation status, each with different speed and security tradeoffs.
- CRL — complete list of all ever-revoked certificates; slowest, most bandwidth-heavy
- OCSP — real-time query for a single certificate's status by serial number; faster than CRL, but unencrypted
- OCSP Stapling — certificate holder pre-fetches and caches the OCSP response, embedding it in the TLS handshake; fastest, eliminates extra round-trip to the CA
Self-signed vs third-party certificate trust model
The difference between self-signed and third-party certificates is entirely about external verification and where trust originates.
- Self-signed: entity vouches for itself; no CA validation; browser warns on public-facing sites; acceptable in testing, development, and closed internal systems
- Third-party: issued by a CA whose root is embedded in browsers/OS; automatically trusted by clients; required for all publicly-facing websites and applications
Key escrow security controls — dual control requirement
Key escrow protects against key loss but creates a high-value target requiring strict access controls.
- At least two administrators must be present simultaneously when retrieving a key (separation of duties)
- Escrow storage must be highly secured to prevent bulk key theft
- Key recovery agents provide software-based restoration of lost/corrupted keys — distinct from escrow agents
Wildcard vs SAN: Primary Distinction
Scenario: 'One certificate needed for www.company.com, mail.company.com, and store.company.com (same root domain)' → Wildcard certificate. Scenario: 'One certificate needed for company.com and partner-company.com (different root domains)' → Subject Alternate Name (SAN). Same root = wildcard; different roots = SAN.
Single-sided vs Dual-sided: Most Likely Indicator
Scenario: 'High-security environment where both server and client must present certificates for mutual authentication' → Dual-sided certificate. Scenario: 'Standard HTTPS website where only the server authenticates to the browser' → Single-sided certificate. Dual-sided = twice the server processing overhead.
Self-signed certificate: Primary Indicator and Use Case
Scenario: 'Browser displays a security warning when connecting to an internal server' → Self-signed certificate (no trusted CA). Scenario: 'Which certificate type is appropriate for a non-production test environment?' → Self-signed. Never use self-signed certificates on public-facing production systems.
CRL vs OCSP vs OCSP Stapling: Performance Order
Slowest to fastest revocation checking: CRL (downloads full revoked list) → OCSP (queries one certificate in real time) → OCSP Stapling (pre-fetched and embedded in TLS handshake). Scenario: 'Reduce TLS handshake latency caused by certificate revocation checking' → Implement OCSP Stapling.
Public Key Pinning: Primary Use Case
Scenario: 'An attacker presents a fraudulent but CA-signed certificate to impersonate a legitimate website' → Public key pinning prevents this by binding expected public keys to the site via HTTP headers. If the presented key does not match the pinned set, the browser alerts the user.
Key Escrow Agent vs Key Recovery Agent: Distinction
Key escrow agent = holds a secure copy of a private key for retrieval when lost. Key recovery agent = software that restores lost or corrupted keys. Scenario: 'Employee leaves and encrypted files are inaccessible' → Key escrow agent. Scenario: 'CA key store is corrupted after a disaster' → Key recovery agent.
CSR: What stays with the requester
Scenario: 'Which part of the certificate signing request is NOT sent to the Certificate Authority?' → The private key. The CSR sends entity information and the public key to the CA. The private key always remains exclusively with the requester.
Exploring Digital Certificates (OBJ 1.4)
ECC (Elliptic Curve Cryptography)
An asymmetric encryption algorithm that achieves high security with smaller key sizes by exploiting the mathematical structure of elliptic curves. A 256-bit ECC key provides security equivalent to a 2,048-bit RSA key with significantly less computational overhead.
RSA (Rivest–Shamir–Adleman)
An asymmetric encryption algorithm based on the mathematical difficulty of factoring large prime numbers. Widely used for digital certificates and secure key exchange; standard key sizes are 2,048 or 4,096 bits.
Certificate Subject
The field in a digital certificate that identifies the entity the certificate was issued to, including the organization name, locality (city, state, country), and common name (typically the domain or server name).
Certificate Issuer
The field in a digital certificate that identifies the Certificate Authority (CA) that issued and signed the certificate. Allows clients to trace the certificate's trust chain back to a known trusted root CA.
Certificate Fingerprint
A unique hash value derived from the certificate's entire contents, serving as a globally unique identifier for that specific certificate. Used to verify certificate integrity and distinguish it from all other certificates.
Digital certificate anatomy — fields in a public key certificate
A digital certificate contains structured fields that allow any party to verify the identity of the certificate holder and the integrity of the certificate.
- Subject — who the certificate was issued to (organization name, location)
- Issuer — the Certificate Authority that signed and issued it
- Validity period — not-before and not-after dates defining the active window
- Public key info — algorithm type (ECC, RSA) and key size in bits
- Signature algorithm — hash algorithm used to sign the certificate (e.g., SHA-256 provides integrity)
- Certificate fingerprint — unique hash identifier for this specific certificate
ECC vs RSA — key size and use case comparison
ECC and RSA are both asymmetric algorithms used in digital certificates but differ in key size required for equivalent security.
- ECC 256-bit ≈ RSA 2,048-bit in security strength — nearly 10× smaller key, equivalent protection
- ECC: smaller key → less computation → preferred for mobile and low-power devices
- RSA: larger key → more computation → used when desktop-class processing power is available
- Both are valid for HTTPS; server selects algorithm based on expected client environment
SHA-256 role in digital certificates
SHA-256 is used as the signature algorithm in a digital certificate to provide integrity. It hashes the certificate contents so that any tampering invalidates the signature and is detectable by any relying party.
ECC vs RSA: Primary Use Case Distinction
Scenario: 'Organization wants to minimize certificate processing overhead on mobile and low-power devices' → ECC certificate (256-bit). Scenario: 'Desktop-focused application with ample server processing capacity' → RSA certificate (2,048-bit). ECC achieves equivalent security with a much smaller key.
Most Likely Equivalent: ECC 256-bit vs RSA 2,048-bit
The exam may ask which key sizes across different algorithms provide equivalent security. ECC 256-bit ≈ RSA 2,048-bit. Despite being nearly 10 times smaller in bit count, an ECC 256-bit key is not weaker — the mathematics of elliptic curves provides the same level of protection.
SHA-256 in a certificate: what it provides
Scenario: 'What does the SHA-256 signature algorithm provide in a digital certificate?' → Integrity. SHA-256 hashes the certificate contents; any modification to the certificate invalidates the hash, making tampering detectable. It does not provide confidentiality or authentication by itself.
Certificate fields: Subject vs Issuer distinction
Scenario: 'Which certificate field identifies who the certificate was issued to?' → Subject (contains organization name and domain). Scenario: 'Which certificate field identifies the trusted CA that vouches for the certificate?' → Issuer. Subject = the holder; Issuer = the CA that signed it.
Blockchain (OBJ 1.4)
Blockchain
A shared immutable ledger for recording transactions, tracking assets, and building trust. Implemented as a decentralized peer-to-peer network where each block is cryptographically chained to the previous one using hashes, making retroactive alteration detectable.
Public Ledger
A record-keeping system within a blockchain that maintains participants' identities in a secure and anonymous format, tracks cryptocurrency balances, and records all genuine transactions executed between network participants.
Smart Contract (Digital Contract)
A self-executing contract where the terms and conditions are written directly into code. Automatically executes actions when specified conditions are met without the need for intermediaries; once deployed on a blockchain, it cannot be altered.
Permissioned Blockchain
A blockchain variant used for business transactions that restricts participation to approved parties. Promotes trust and transparency through immutable public ledgers while controlling who can read, write, or validate transactions.
Blockchain block structure — what each block contains
Each block in a blockchain is cryptographically linked to the previous block, making tampering with any historical record detectable across the entire chain.
- Previous hash — hash of the preceding block, creating the unbreakable chain
- Timestamp — records when the block was last modified
- Transaction hashes — individual transactions each produce a hash; pairs of hashes are combined (Merkle tree structure) up to a single root hash for the block
- Altering any transaction changes its hash, invalidating every subsequent block
Blockchain core security properties
The security value of blockchain derives from three interdependent properties.
- Immutability — recorded data cannot be changed without invalidating the entire chain; no single entity can alter history
- Decentralization — no central authority; the ledger is distributed across all network participants
- Transparency — all participants can verify the record; transactions are visible and auditable
Blockchain use cases beyond cryptocurrency
Blockchain's immutability and transparency make it applicable across industries where trusted, tamper-proof records are required.
- Supply chain management — end-to-end traceability of goods from origin to consumer
- Smart contracts — automated, intermediary-free execution of business agreements
- Voting systems — tamper-evident, auditable election records
- Property transfers — transparent ownership records without centralized registries
- Intellectual property protection — timestamped, immutable proof of creation
Primary property: blockchain provides immutability
Scenario: 'Organization needs a record system where historical entries cannot be modified or deleted without detection' → Blockchain (immutable ledger). Scenario: 'Which blockchain property prevents retroactive alteration of transaction records?' → Immutability via hash chaining — changing any block invalidates all subsequent blocks.
Smart Contract: Primary Indicator
Scenario: 'Funds are automatically released to a vendor when delivery is confirmed, without manual approval' → Smart contract. Key identifiers: self-executing, conditions coded directly, no intermediary required, deployed on a blockchain and cannot be altered after deployment.
Permissioned vs Public Blockchain: Use Case Distinction
Scenario: 'Enterprise wants blockchain for internal business transactions with controlled access' → Permissioned blockchain. Scenario: 'Cryptocurrency network open to any participant' → Public blockchain. Permissioned = restricted participation + business context; Public = open peer-to-peer network.
Supply chain: Most Likely Blockchain Application
Scenario: 'Organization needs end-to-end traceability of products from manufacturer to consumer with tamper-proof records' → Blockchain / permissioned blockchain. The immutable public ledger ensures that provenance data cannot be modified by any single party in the chain.
Blockchain vs traditional database: Key Distinction
Blockchain is decentralized (no single authority), immutable (past records cannot be changed), and transparent (all participants can verify). A traditional database is centralized, mutable (records can be updated or deleted), and access-controlled by an administrator.
Encryption Tools (OBJ 1.4)
TPM (Trusted Platform Module)
A dedicated microcontroller designed to secure hardware through integrated cryptographic keys, offering hardware-level security to ensure digital secrets remain confidential and unaltered. Commonly used with BitLocker drive encryption in Windows.
HSM (Hardware Security Module)
A physical computing device that safeguards and manages digital keys and performs encryption operations within a tamper-proof environment. Used for mission-critical applications such as financial transactions and regulatory compliance.
KMS (Key Management System)
An integrated, centralized approach for generating, distributing, and managing cryptographic keys for devices and applications across the entire key lifecycle, from creation through retirement and destruction.
Secure Enclave
A co-processor integrated into the main processor of a device, isolated from the main processor, designed solely to provide a shielded location for the safe processing and storage of sensitive data such as biometric credentials.
Four encryption tools — purpose and use case summary
The exam distinguishes these four tools by their scope, environment, and primary function.
- TPM — device-level microcontroller; secures cryptographic keys in hardware; primary use: BitLocker full-disk encryption on Windows
- HSM — enterprise physical appliance; tamper-proof key generation and encryption operations; primary use: financial transactions, regulatory compliance
- KMS — centralized software/service system; manages the full cryptographic key lifecycle (generate → distribute → manage → retire/destroy)
- Secure Enclave — isolated co-processor inside main CPU; stores biometric and highly sensitive data that never leaves the device
Key lifecycle managed by KMS
A key management system controls cryptographic keys through every stage of their existence to prevent unauthorized access and enforce periodic renewal.
- Generation — creates cryptographic keys
- Distribution — delivers keys securely to authorized devices and applications
- Management — tracks active keys and enforces rotation policies
- Retirement and destruction — safely expires and deletes old keys when new ones are introduced
Secure Enclave — isolation from main processor
The secure enclave operates independently of the main processor and OS. Even if the device is fully compromised, data within the secure enclave remains inaccessible. Biometric data (Face ID, Touch ID) is stored in the secure enclave and never transmitted off the device.
TPM vs HSM: Primary Scope Distinction
Scenario: 'Organization wants to protect encryption keys at the device level to support full-disk encryption on employee laptops' → TPM. Scenario: 'Financial institution needs a tamper-proof appliance to generate and store keys for high-volume payment transactions and meet compliance requirements' → HSM. TPM = device-level; HSM = enterprise/mission-critical.
TPM: Most Likely Association with BitLocker
Scenario: 'Which hardware component stores the encryption keys used by BitLocker drive encryption?' → TPM (Trusted Platform Module). BitLocker relies on the TPM to secure the volume encryption key at the hardware level, preventing software-based attacks from accessing the key.
HSM: Primary Use Case Indicators
Scenario: 'Organization must meet PCI-DSS requirements and needs encrypted financial transactions with keys that never exist in software' → HSM. Key identifiers: tamper-proof/tamper-resistant hardware, regulatory compliance, accelerated cryptographic operations, mission-critical or financial context.
KMS: Primary Indicator for Key Lifecycle
Scenario: 'Cloud storage platform needs to automatically generate, rotate, and retire encryption keys for millions of files without manual administration' → Key Management System (KMS). KMS is the answer when the scenario involves automating or centralizing the full key lifecycle, not just storage.
Secure Enclave: Primary Indicator for Biometric Isolation
Scenario: 'Mobile device stores fingerprint and facial recognition data in a location that remains protected even if the operating system is compromised' → Secure Enclave. The secure enclave is isolated from the main processor; biometric data processed there never leaves the device.
TPM vs Secure Enclave: Key Distinction
TPM is a separate dedicated microcontroller chip added to a device's motherboard; primarily used for full-disk encryption key storage (BitLocker). Secure Enclave is a co-processor integrated inside the main CPU die; primarily used for biometric data and mobile device security. Both are hardware-isolated, but their scope and integration differ.
Obfuscation Techniques (OBJ 1.4)
Obfuscation
The practice of making data unclear, difficult to interpret, or hidden without necessarily encrypting it. Obfuscation techniques — steganography, tokenization, and data masking — conceal sensitive data in different ways and are used alongside encryption for layered security.
Steganography
The practice of hiding secret data within ordinary, non-secret files or messages to avoid detection. The primary goal is not to prevent unauthorized access to the data but to prevent the suspicion that any hidden data exists at all.
Tokenization
The process of substituting sensitive data elements with nonsensitive equivalents called tokens, which have no intrinsic or exploitable meaning. The original data is securely stored in a separate vault; only authorized systems can map tokens back to the actual values.
Data Masking
Also called data obfuscation. The process of disguising original data to protect sensitive information while maintaining the data's authenticity and usability for a specific purpose. Creates a sanitized version of data for non-production environments or restricted employee access.
Three obfuscation techniques — steganography, tokenization, data masking
All three operate under the principle of hiding information, but by different mechanisms and for different purposes.
- Steganography — embeds a hidden message inside another ordinary file (image, audio, text); adversaries remain unaware any hidden data exists; data is NOT encrypted, only concealed
- Tokenization — replaces sensitive data (e.g., credit card numbers) with random tokens that have no value outside the issuing system; actual data stored in a secure vault; reduces Payment Card Industry Data Security Standard (PCI-DSS) compliance scope
- Data masking — replaces real data with realistic-looking but non-sensitive substitutes; used in dev/test environments so developers can work with realistic data without exposing real customer records, or in employee-facing systems that display only partial data (e.g., last four digits of a card or SSN)
Steganography used alongside encryption
Encryption announces there is something worth hiding; steganography hides the data in plain sight so detection itself becomes the challenge. Using both layers means an adversary must first detect that hidden data exists, then break the encryption to read it.
Primary distinction: steganography hides existence; encryption hides content
Scenario: 'data hidden inside an image file so no one suspects a message is present' → Steganography. Scenario: 'data transformed into unreadable ciphertext requiring a key to reverse' → Encryption. Steganography conceals that data exists; encryption conceals what the data says.
Critical trap: steganography does NOT encrypt data
Note thatsteganography data is 'not encrypted, just hidden in plain sight.' Scenario: 'an image contains a hidden message using steganography — what security property is absent?' → Confidentiality/encryption. Anyone who locates and extracts the hidden data can read it without a key.
Tokenization: Primary indicator is payment systems and PCI-DSS scope reduction
Scenario: 'merchant replaces customer credit card numbers with random strings so that a data breach exposes only useless tokens, not actual card data' → Tokenization. Key identifiers: payment systems, PCI-DSS compliance, tokens stored by merchant, real data kept in a separate secure vault.
Data masking: Most likely answer for dev/test environments or partial employee access
Scenario: 'developers need realistic test data without exposing actual customer records' → Data masking. Scenario: 'support staff can only see the last four digits of a customer credit card' → Data masking. Both describe disguising real data while preserving usability.
Distinction: tokenization vs data masking
Tokenization replaces data with a token that maps back to the original in a vault — the original value is preserved and recoverable by authorized systems. Data masking replaces data with altered but realistic-looking values — the original value is not recovered from the masked version. Tokenization is for live transactional systems; data masking is for non-production or restricted-display contexts.
Cryptographic Attacks (OBJ 1.4)
Cryptographic Attack
Techniques and strategies adversaries use to exploit vulnerabilities in cryptographic systems to compromise confidentiality, integrity, and authenticity. Methods include exploiting algorithm weaknesses, leveraging implementation flaws, impersonating users, creating forgeries, or using brute-force to guess keys.
Downgrade Attack (Version Rollback Attack)
Forces a system to use a weaker or older cryptographic standard or protocol than what it currently supports, enabling an attacker to exploit known vulnerabilities in those outdated versions that have been addressed in newer, more secure protocols.
POODLE Attack — Padding Oracle On Downgraded Legacy Encryption
A downgrade attack that forced victim systems to revert from TLS to SSL 3.0, allowing attackers to exploit SSL 3.0 padding vulnerabilities and extract sensitive data from communications. A named real-world example of a downgrade attack.
Collision Attack
An attack that finds two different inputs producing the same hash output. If successful, an attacker can substitute a malicious file with the same hash value as a legitimate original, defeating hash-based integrity verification and allowing forgery of digital signatures or distribution of tampered data.
Birthday Attack (Birthday Paradox)
A collision attack based on the Birthday Paradox: in a group of just 23 people, there is a greater than 50% chance two share a birthday. Applied to cryptography, this demonstrates that finding hash collisions in fixed-output algorithms (MD5, SHA-1, SHA-256) may be far more probable than initially perceived.
MD5 — Message Digest Algorithm 5
A hashing algorithm rendered unsuitable for security certificates and encryption technologies after researchers demonstrated that two different inputs could be crafted to produce the same MD5 hash, making collision attacks feasible. MD5 should not be used for integrity verification in any security-sensitive context.
Quantum Computing
A computing model that uses quantum mechanics to generate and manipulate quantum bits (qubits), accessing enormous processing power for complex mathematical problems. Quantum computers are specifically well-suited for factoring large prime numbers and solving discrete logarithm problems — the hard math underpinning asymmetric encryption.
Qubit
A quantum bit — the fundamental unit of quantum computing, composed of electrons or photons. Unlike a classical bit (strictly 0 or 1), a qubit can represent multiple combinations of ones and zeros simultaneously via superpositioning, enabling massive parallel computation across potential outcomes.
Superpositioning
The quantum property that allows a qubit to exist in multiple states (combinations of 0 and 1) simultaneously rather than being restricted to a single binary value. This allows quantum computers to evaluate many potential outcomes at once, dramatically accelerating certain mathematical calculations such as prime factorization.
Quantum Communications
A communications network that relies on qubits made of photons (light) to send multiple combinations of ones and zeros simultaneously, resulting in tamper-resistant and extremely fast communications. Distinct from quantum computing — quantum communications uses qubits for data transmission, not processing.
Post-Quantum Cryptography
A class of cryptographic algorithms designed to run on today's classical computers but remain impervious to attacks from future quantum computers. Addresses the imminent threat quantum computing poses to asymmetric encryption algorithms such as RSA and ECC.
CRYSTALS-Kyber
The NIST-selected post-quantum algorithm for general encryption. Uses relatively small encryption keys and is based on the difficulty of solving learning with errors (LWE) problems over modular lattices. Provides security roughly equivalent to AES-256 symmetric encryption.
NIST Post-Quantum Digital Signature Algorithms (2022)
In 2022, NIST completed a six-year competition and selected three post-quantum digital signature algorithms.
- CRYSTALS-Dilithium — NIST's primary recommendation for post-quantum digital signatures; based on the difficulty of solving structured lattice problems
- FALCON — alternative post-quantum signature algorithm; also based on structured lattice problems
- SPHINCS+ — alternative post-quantum signature algorithm; uniquely based on hash functions rather than lattice problems
How downgrade attacks work and their countermeasures
Systems support multiple protocol versions for backward compatibility; attackers exploit the handshake negotiation to falsely present an older, weaker protocol version as the highest both parties support.
- Mechanism: attacker intercepts handshake and manipulates version negotiation, causing both systems to use a vulnerable legacy protocol they believe is mutually compatible
- Countermeasure 1: phase out legacy protocol support entirely, accepting loss of backward compatibility to eliminate the attack surface
- Countermeasure 2: version intolerance checks — system initially claims to support only the latest protocol version; any forced downgrade exposes the attacker's manipulation
Quantum computing threatens asymmetric encryption; symmetric is more resilient
Asymmetric encryption (RSA, ECC) derives its strength from the mathematical difficulty of factoring large prime numbers or solving discrete logarithm problems — calculations quantum computers can solve rapidly. Asymmetric algorithms have been mathematically proven to be breakable by quantum computers.
- Asymmetric (RSA, ECC) — primary and immediate target; all key exchanges and digital signatures based on prime factoring or discrete logarithms are at risk
- Symmetric (AES) — more resilient; mitigation is to double the key length (AES-128 → AES-256), which squares — not doubles — the number of permutations a quantum attacker must evaluate
- Operational status: no quantum computers are currently in production; government and large corporate use is estimated no earlier than 2030
Post-quantum cryptography mitigation approaches
Two tracks address the quantum computing threat to existing cryptographic systems.
- Increase key size (symmetric algorithms) — doubling the key length squares the keyspace, making brute-force by quantum computers exponentially harder; viable for AES today
- Lattice-based algorithms — CRYSTALS-Kyber (encryption), CRYSTALS-Dilithium, and FALCON (signatures) rely on the hardness of lattice mathematical problems that quantum computers cannot efficiently solve
- Hash-based algorithms — SPHINCS+ uses hash function hardness instead of lattice problems as its security foundation; selected by NIST as an alternative post-quantum signature scheme
POODLE: Primary scenario indicators are SSL 3.0 downgrade and padding oracle
Scenario: 'attacker manipulates TLS handshake and forces connection to revert to SSL 3.0, extracting session data via padding vulnerabilities' → POODLE. Key identifiers: downgrade from TLS to SSL 3.0, padding oracle exploitation, attacker intercepting version negotiation.
Collision attack: Primary indicator is two inputs with identical hash output
Scenario: 'attacker crafts a malicious file that produces the same MD5 hash as a legitimate download, allowing undetected substitution' → Collision attack. Scenario: 'digital signature forged by producing a document with the same hash as the signed original' → Collision attack exploiting hash weakness.
MD5: Most likely wrong answer when selecting a secure hashing algorithm
Scenario: 'which hashing algorithm is appropriate for signing security certificates or verifying file integrity in a production security system?' → MD5 is not acceptable; collision attacks have been demonstrated against it. Correct alternatives: SHA-256 or SHA-3.
Quantum threat: Primary target is asymmetric encryption — RSA and ECC
Scenario: 'emerging technology that defeats encryption by rapidly factoring the large prime numbers that RSA and ECC rely on' → Quantum computing. Symmetric encryption (AES) is not the primary target — key size increase provides mitigation. Asymmetric key exchange and digital signatures carry the highest risk.
Quantum computing is theoretical today — not yet an operational threat
Scenario: 'organization must act immediately to replace all encryption because quantum computers have broken RSA' → Incorrect framing; no operational quantum computers currently exist in production. The correct framing is that organizations should begin transitioning to post-quantum algorithms before quantum computers become operational (estimated 2030 for government use).
NIST post-quantum: Kyber for encryption, Dilithium as primary for signatures
Scenario: 'post-quantum algorithm for general encryption' → CRYSTALS-Kyber. Scenario: 'NIST's primary recommendation for post-quantum digital signatures' → CRYSTALS-Dilithium. FALCON and SPHINCS+ are alternatives for signatures; SPHINCS+ is the only one that uses hash functions rather than lattice-based math.
Distinction: downgrade attack vs collision attack
Downgrade attack targets the protocol negotiation phase — it forces use of a weaker protocol version during the handshake. Collision attack targets the hash output — it finds two inputs producing the same hash value. Both undermine cryptographic integrity but through entirely different mechanisms and at different layers.