Cryptographic Solutions — CISSP Study Guide

Three classes, three properties: the selection model

CISSP almost never asks you to recite an algorithm's internals; it asks which kind of cryptography solves a stated problem, so the entire subtopic hangs on one move: name the CIA property the requirement needs, then pick the algorithm class whose primary effect is that property. Three classes preserve three different properties, and one construct, the digital signature, deliberately crosses property boundaries and is tested heavily because of it. Master that property-to-class map (it presumes you already carry the CIA pillars from Security & Risk Management → Security Concepts) and most stems answer themselves.

The figure above maps the three classes to the property each preserves, with the digital signature spanning the asymmetric and hash classes. Symmetric cryptography uses a single secret key shared by both parties to encrypt and decrypt; its property is confidentiality. The Advanced Encryption Standard (AES)^[1] is the canonical example, "a symmetric block cipher that can encrypt and decrypt information," specified in FIPS 197. Asymmetric cryptography (public-key cryptography) uses a mathematically linked key pair, a public key anyone may hold and a private key kept secret; its property is also confidentiality, but it additionally solves key distribution and underpins signatures. RSA and elliptic-curve cryptography (ECC) are the examples to know. Hash functions (SHA-2, SHA-3) take any input and produce a fixed-length digest; their property is integrity: any change to the input changes the digest. A hash uses no key, so on its own it cannot prove who produced the data.

The one construct that crosses property boundaries is the digital signature, and the exam leans on it heavily. A signature hashes the message and then encrypts that hash with the signer's private key; a verifier decrypts it with the signer's public key and recomputes the hash. Per FIPS 186-5, the Digital Signature Standard^[2], a digital signature "verifies origin authenticity and data integrity and enforces signatory non-repudiation." So a single signature delivers three properties at once: integrity (the hash detects alteration), authenticity (only the private-key holder could have produced it), and non-repudiation (a third party can prove who signed). Hold onto the asymmetry, one party holds the private key, because the next section shows it is exactly why a shared-key MAC cannot give non-repudiation.

A term the exam treats as a near-synonym but is not: encoding (Base64), encryption, and hashing are three different things. Encoding is reversible and uses no key (it is not a security control); encryption is reversible with a key (confidentiality); hashing is one-way (integrity). Treating Base64 or a hash as "encryption" is a classic distractor.

Three classes mapped to the property each preserves; the digital signature spans asymmetric and hash to add authenticity and non-repudiation.

Symmetric vs. asymmetric, MAC vs. signature, and the hybrid pattern

This section explains the mechanics behind the selection model: why symmetric and asymmetric have opposite strengths, why a MAC and a signature look alike but differ on one property, and how the hybrid pattern combines them. The unifying idea is that symmetric is fast but cannot distribute its own key; asymmetric distributes keys but is slow, so real systems use each for what it is good at.

Symmetric: fast, but key distribution does not scale

Symmetric ciphers like AES are fast enough to encrypt full disks and network streams in real time. Two structural problems follow from the single shared key. First, distribution: both endpoints need the same secret, and there is no safe way to hand it across an open channel. Encrypting the key needs another key, which is the same problem again. Second, scale: n parties who must all talk pairwise need roughly n(n-1)/2 distinct keys, which explodes. Block ciphers also need a mode of operation: never use ECB (Electronic Codebook), which encrypts identical plaintext blocks to identical ciphertext and leaks structure; authenticated modes like GCM provide confidentiality and integrity together.

Asymmetric: solves distribution, pays in speed

Asymmetric crypto breaks the distribution problem with a key pair. Publish your public key freely; anyone can encrypt to it, but only your private key decrypts, so no secret ever crosses the wire. The direction reverses for signatures: you sign with your private key and the world verifies with your public key. The trade-off is performance: RSA and ECC are orders of magnitude slower than AES, so they are used on small data (keys, hashes), not bulk. ECC delivers equivalent security to RSA at a much smaller key size (a ~256-bit ECC key is comparable to a ~3072-bit RSA key) which is why constrained and mobile devices prefer it. Diffie-Hellman is a third asymmetric primitive: it does not encrypt or sign, it lets two parties derive a shared secret over a public channel; using ephemeral DH keys per session gives perfect forward secrecy^[3], so a later private-key compromise cannot decrypt past sessions.

MAC vs. HMAC vs. digital signature: the property that separates them

All three protect integrity, so the exam separates them by which extra property they add. A Message Authentication Code (MAC), and its hash-based form HMAC, uses a shared secret key: it proves integrity and authenticity between two parties who already share the key. But because both hold the same key, a MAC provides authenticity and integrity but NOT non-repudiation, either party could have produced the tag^[4]. A digital signature uses an asymmetric key pair, so the signing key is held by exactly one party; that single-holder property is what lets an outside arbiter attribute the act, giving the non-repudiation a MAC cannot. Reconcile the two clearly: a MAC and a signature both "prove who sent it" between the two parties, but only the signature proves it to a third party, because only the signature's key is held by one party alone.

The hybrid cryptosystem

The figure above shows how protocols like TLS resolve the speed/distribution tension. The sender generates a random one-time symmetric session key, encrypts the bulk data with that fast key, then encrypts the small session key with the recipient's public key and sends both. The recipient uses their private key to recover the session key, then decrypts the data symmetrically. Asymmetric crypto is used only on the tiny session key; the heavy lifting stays symmetric. This is why "use asymmetric to encrypt the whole file" is wrong. Asymmetric encrypts the key, not the payload.

The hybrid cryptosystem: asymmetric crypto ships a one-time symmetric session key, then the fast symmetric cipher protects the data.

The key lifecycle, key management, and PKI

Algorithms rarely break in practice; key management does, so the lifecycle and PKI are where exam questions and real incidents concentrate. Building on the algorithm classes above, this is what a security leader actually governs: keys over their lifecycle, and the PKI that makes public keys trustworthy.

The key lifecycle and cryptoperiod

Treat every key as moving through phases: generation → distribution/exchange → storage → use → rotation → destruction. Each phase carries its own control. Generation must draw from a vetted random source: predictable keys are the weakest link. Distribution uses asymmetric crypto or key-wrapping so the secret never travels in the clear. Storage belongs in hardware: a Hardware Security Module (HSM) generates and holds keys so the private key never leaves tamper-resistant hardware, and keys are stored separately from the data they protect. A key is authorized only for a bounded cryptoperiod^[5] ("the time span during which a specific key is authorized for use") after which it is rotated, so that compromising one key exposes only a limited window. Destruction (per the data-remanence rules in Asset Security) must make retired keys unrecoverable. Two governance specifics the exam likes: key escrow stores a copy of a key with a trusted third party so the organization (or law enforcement under proper authority) can recover data, and M-of-N control / split knowledge requires several custodians to act together so no single person controls a critical key.

PKI: turning a public key into a trusted identity

A public key is just a number; trust comes from a certificate that binds the key to an identity and is signed by an authority the relying party trusts. Public Key Infrastructure (PKI) is "a framework that is established to issue, maintain and revoke public key certificates."^[6] The figure shows the chain of trust. A Registration Authority (RA) vets the requester's identity; the Certificate Authority (CA) then issues a signed X.509 certificate. CAs are layered: a tightly protected, usually offline root CA signs intermediate (subordinate) CAs, which sign end-entity certificates, so a root-key compromise is rare and an intermediate can be revoked without reissuing everything. A relying party trusts a certificate by validating the chain up to a root already in its trust store.

Revocation: why expiry alone is not enough

A private key can be lost or stolen before its certificate expires, so relying parties must check revocation. Reconcile the two mechanisms at the point of choice: a Certificate Revocation List (CRL) is a CA-signed list of revoked serial numbers that clients download, simple but stale between publications and large at scale; the Online Certificate Status Protocol (OCSP) answers "is this one certificate still valid?" in real time, and OCSP stapling has the server attach a recent signed status so the client need not contact the CA. Choose OCSP when freshness matters; a CRL is the fallback. The reusable rule: a valid certificate is one that chains to a trusted root, is unexpired, and is not revoked (all three, not just the signature).

PKI chain of trust: a trusted root signs intermediates that sign end-entity certificates; an RA vets identity and CRL/OCSP publishes revocation.

Quantum, and exam-pattern recognition

The exam rewards naming the right property and the right class, and reasoning about migration as a leadership decision, not reciting key sizes. Building on the prior three sections, this adds the quantum horizon and then shows how cryptography surfaces in CISSP question stems.

Quantum and post-quantum cryptography

The figure above splits cryptography into the two impact classes that follow. A large-scale quantum computer would break today's asymmetric algorithms: Shor's algorithm efficiently factors large integers and solves discrete logarithms, defeating RSA, ECC, and Diffie-Hellman. Symmetric ciphers and hashes are only weakened: Grover's algorithm roughly halves their effective security, which is countered by doubling key/output size (e.g. AES-256 stays strong). NIST finalized its first post-quantum standards in August 2024: ML-KEM (FIPS 203, from CRYSTALS-Kyber) for key encapsulation, ML-DSA (FIPS 204, from CRYSTALS-Dilithium) and SLH-DSA (FIPS 205, from SPHINCS+) for signatures^[7]. Quantum key distribution (QKD) is a different idea: it uses quantum physics (not math) to detect eavesdropping on a key exchange, but it needs special hardware and does not replace authentication, so NIST and NSA guidance favors post-quantum algorithms over QKD for general use. The leader's move is the harvest-now-decrypt-later defense: adversaries can record encrypted traffic today and decrypt it once quantum computers arrive, so data with a long confidentiality lifetime should migrate to PQC now.

Exam-pattern recognition

Pattern 1: "Which provides non-repudiation?" This is the single most-tested crypto distinction. If the stem wants the sender unable to deny the act to a third party (watch for "deny," "dispute," "prove to an auditor/court," "legally binding"), the answer is an asymmetric digital signature, never a MAC/HMAC, which fails because both parties share the key, and never plain encryption.

Pattern 2: confidentiality is not authentication. A stem that says data was encrypted and asks whether the recipient can trust its origin is testing the conflation. Encryption gives confidentiality only; add a signature or MAC to establish origin. "The message is encrypted, therefore we know who sent it" is the wrong answer.

Pattern 3: "Why does the protocol use both symmetric and asymmetric?" The (ISC)2-correct reason is performance with secure key distribution: asymmetric crypto safely exchanges a symmetric session key, then the fast symmetric cipher encrypts the bulk data. Distractors invert this: "asymmetric encrypts the data because it is more secure" misstates how hybrid systems work.

Pattern 4: certificate trust and revocation. When a stem presents an expired, self-signed, or revoked certificate, the binding is untrustworthy regardless of a valid signature. If the requirement is real-time revocation checking, the answer is OCSP; a CRL is the periodic-download fallback. "Trust it because the signature verifies" ignores expiry and revocation.

Pattern 5: key management over algorithm choice. When asked for the BEST way to protect keys, the manager-altitude answer governs the lifecycle: generate from good randomness, store private keys in an HSM separated from the data, enforce a cryptoperiod and rotation, and destroy retired keys. An answer that fixates on picking a longer key while ignoring how the key is stored or rotated is the trap.

Pattern 6: quantum readiness. When a stem asks how to protect long-lived sensitive data against future quantum attack, the answer is to adopt NIST post-quantum algorithms now (harvest-now-decrypt-later), not to wait for a quantum computer and not to assume QKD is a drop-in replacement for authentication.

Quantum splits crypto in two: Shor's breaks asymmetric (RSA, ECC, DH); Grover's only halves symmetric and hashes, so doubling key size answers it.

Choosing a cryptographic class by the property it preserves

Property / trait	Symmetric (AES)	Asymmetric (RSA / ECC)	Hash (SHA-2/3)	Digital signature
Primary property	Confidentiality	Confidentiality + key exchange	Integrity	Integrity + authenticity + non-repudiation
Keys	One shared secret key	Public/private key pair	No key (keyed = HMAC)	Signer's private key + verifier's public key
Speed	Fast (bulk data)	Slow (small data, key setup)	Very fast	Slow (hash then sign)
Key distribution	Hard: secret must be pre-shared	Easy: public key is published	N/A	Public key distributed via PKI cert
Provides non-repudiation	No	Via signature only	No	Yes (single-holder private key)
Quantum exposure	Weakened: use larger keys	Broken by Shor's algorithm	Weakened: use larger output	Broken (asymmetric): migrate to PQC

Decision tree

Cheat sheet

Sharp facts the exam loves — give these one last read before exam day.

Cheat sheet

Sharp facts the exam loves — scan these before test day.

Pick the cryptographic class by the property the asset needs, not by strength

Cryptography splits into three classes that preserve different properties: symmetric and asymmetric ciphers give confidentiality, hash functions give integrity, and a digital signature gives integrity plus authenticity plus non-repudiation together. Reason from the required property first, then choose the class whose primary effect is that property. The recurring exam trap is offering a strong control for the wrong property, so fit beats strength.

Trap Choosing the strongest-sounding algorithm rather than the one whose property matches the requirement, e.g. answering with encryption when the question asks for integrity.

AES is a symmetric block cipher specified in FIPS 197

The Advanced Encryption Standard (AES) is a symmetric block cipher (one shared secret key both encrypts and decrypts) specified in NIST FIPS 197 and used for bulk confidentiality such as full-disk, database, and transport encryption. Symmetric is fast, which is why it carries the data payload rather than asymmetric crypto. Its weakness is not the math but distributing the shared key safely.

Trap Classifying AES as an asymmetric algorithm because it is the headline standard, when the same secret key both encrypts and decrypts.

1 question tests this

A financial services organization is designing a cryptographic architecture for protecting customer data at rest. The security architect…

Symmetric key distribution does not scale, which is the problem asymmetric solves

A symmetric cipher needs both endpoints to hold the same secret, and there is no safe way to hand that secret across an open channel; n parties talking pairwise need about n(n-1)/2 keys, which explodes. Asymmetric cryptography exists precisely to break this: a published public key lets anyone encrypt while only the private key decrypts, so no secret crosses the wire. That is the single reason real protocols pair the two.

Trap Picking weak algorithm strength as symmetric crypto's main weakness when the actual scaling problem is safely distributing the shared secret.

2 questions test this

Never use ECB mode; it leaks plaintext structure

A block cipher needs a mode of operation, and Electronic Codebook (ECB) is the wrong choice because it encrypts identical plaintext blocks to identical ciphertext, leaking patterns in the data. Prefer an authenticated mode such as GCM, which provides confidentiality and integrity at once. The fact that two ciphertext blocks match should never reveal that the underlying plaintext matched.

Trap Treating ECB as acceptable because the cipher (e.g. AES) is strong: the mode, not the cipher, leaks repeating-block structure.

1 question tests this

A security analyst is reviewing an organization's encryption implementation and notices that the same plaintext block consistently produces…

ECC gives RSA-equivalent security at a far smaller key size

Elliptic-curve cryptography (ECC) reaches the same security level as RSA with much shorter keys (roughly a 256-bit ECC key matches a 3072-bit RSA key) so it costs less compute and bandwidth and is preferred on mobile and constrained devices. Both are asymmetric and far slower than symmetric ciphers, so both are used on small data like keys and hashes, not bulk payloads.

Trap Reading ECC's shorter key as weaker than RSA, when a 256-bit ECC key matches a 3072-bit RSA key at the same security level.

Diffie-Hellman exchanges a shared secret without sending it

Diffie-Hellman is an asymmetric primitive that neither encrypts nor signs; it lets two parties derive a shared symmetric secret over a public channel. Using ephemeral Diffie-Hellman keys per session provides perfect forward secrecy, meaning a later compromise of a long-term private key cannot decrypt previously recorded sessions. That property is why modern TLS favors ephemeral key exchange.

Trap Treating Diffie-Hellman as an encryption or signing algorithm, when it only establishes a shared secret and neither encrypts nor signs data.

4 questions test this

Real systems are hybrid: asymmetric ships the key, symmetric carries the data

A hybrid cryptosystem like TLS generates a random one-time symmetric session key, encrypts the bulk data with that fast key, and encrypts only the small session key with the recipient's public key. The recipient uses its private key to recover the session key, then decrypts the data symmetrically. Asymmetric crypto touches just the tiny key, never the payload: that is how systems get both safe key distribution and speed.

Trap Believing asymmetric encryption protects the whole file: it encrypts only the session key; the symmetric cipher encrypts the data.

1 question tests this

A cloud security architect at a media company must protect very large volumes of video assets both at rest and in transit between many…

A hash gives integrity, not confidentiality

A cryptographic hash (SHA-2 or SHA-3) is a one-way function producing a fixed-length digest, so any change to the input changes the digest: that is integrity. It uses no key, so on its own it proves nothing about who produced the data, and being one-way it does not hide data from someone who already has it. Use encryption when secrecy is the goal and a hash when tamper detection is.

Trap Selecting hashing to keep data secret, when a keyless one-way digest provides integrity and does nothing for confidentiality.

A MAC proves authenticity but cannot provide non-repudiation

A Message Authentication Code (MAC), including its hash-based form HMAC, uses a secret key shared by both parties to prove integrity and authenticity between them. But because both hold the same key, either could have produced the tag, so a MAC cannot give non-repudiation: an outside party can't attribute the act to one signer. Reach for a MAC when two known parties just need to trust each other's messages.

Trap Crediting a MAC or HMAC with non-repudiation, when the shared key means either party could have produced the tag and a third party cannot attribute it.

Only an asymmetric digital signature provides non-repudiation

A digital signature hashes the message and encrypts the hash with the signer's private key; a verifier checks it with the signer's public key. Per FIPS 186-5 it delivers data integrity, origin authenticity, and signatory non-repudiation at once, and non-repudiation holds only because the private key is held by exactly one party, letting a third party attribute the act. When a question wants the signer unable to deny it to an auditor or court, the answer is a digital signature.

Trap Answering MAC or HMAC for non-repudiation: the shared key means either party could have produced the tag, so it fails third-party attribution.

1 question tests this

A security architect at a financial services firm is designing how legally binding contracts will be executed electronically with external…

FIPS 186-5 approves RSA, ECDSA, and EdDSA for signatures

The Digital Signature Standard, FIPS 186-5 (2023), specifies the approved signature algorithms RSA, ECDSA, and EdDSA, and supersedes FIPS 186-4. It exists to detect unauthorized modification, authenticate the signatory, and provide non-repudiation. Knowing the standard's name and that signatures are asymmetric is the testable core, not the algorithm internals.

Encryption, hashing, and encoding are three different things

Encoding such as Base64 is reversible and keyless and is not a security control; encryption is reversible with a key and gives confidentiality; hashing is one-way and gives integrity. Conflating them is a classic distractor, especially treating Base64 or a hash as if it were encryption. Name the operation by whether it is reversible and whether it uses a key.

Trap Calling Base64 encoding or a hash digest 'encryption': neither hides data with a key.

Most cryptographic failures are key-management failures, so govern the lifecycle

Algorithms rarely break in practice; keys do, through poor handling. Treat every key as moving through generation, distribution/exchange, storage, use, rotation, and destruction, and put a control on each phase. Generate from a vetted random source, distribute without exposing the secret, store private keys in hardware separated from the data, rotate on schedule, and destroy retired keys so they cannot be recovered.

Trap Hardening the algorithm or key length when the BEST control is governing the key's whole lifecycle, where real-world failures happen.

A key is authorized only for its cryptoperiod, then it must be rotated

A cryptoperiod is the time span during which a specific key is authorized for use (NIST SP 800-57); at its end the key is retired and replaced. Bounding the cryptoperiod limits the damage of a compromise to a single window of data rather than everything the key ever protected. This is why key rotation is a policy requirement, not an optional hygiene step.

1 question tests this

An enterprise security architect is designing a key rotation policy for cryptographic keys used in a data encryption system. The system…

Store private keys in an HSM, separated from the data they protect

A Hardware Security Module (HSM) generates and holds keys inside tamper-resistant hardware so the private key never leaves it in the clear, and keys are kept separate from the data they encrypt so one compromise does not yield both. When a question asks the BEST way to protect keys, the lifecycle answer (HSM storage, rotation, destruction) beats simply picking a longer key.

Trap Fixating on a larger key size while leaving the private key poorly stored. Key handling, not key length, is usually the weak point.

1 question tests this

During a security assessment, a penetration tester discovers that an application stores password hashes using bcrypt with a work factor of…

Key escrow and split knowledge govern recovery and custody

Key escrow stores a copy of a key with a trusted third party so the organization, or law enforcement under proper authority, can recover encrypted data if the key is lost. Split knowledge with M-of-N control requires several custodians to act together to use a critical key, so no single person can wield or expose it alone. The two address different risks: escrow is about recoverability, split knowledge about insider control.

Trap Reaching for key escrow to stop a single insider from misusing a key, when recoverability is escrow's purpose and split knowledge is what enforces dual control.

2 questions test this

A public key becomes trustworthy only through a PKI-issued certificate

A public key is just a number; trust comes from an X.509 certificate that binds the key to an identity and is signed by a Certificate Authority the relying party already trusts. Public Key Infrastructure (PKI) is the framework that issues, maintains, and revokes those certificates, with a Registration Authority vetting identity before the CA signs. Without a trusted issuer in the chain, the binding means nothing.

Trap Trusting a public key on its own because it works mathematically, when trust requires a CA-signed certificate binding that key to a verified identity.

Trust flows down a chain from a protected root through intermediate CAs

PKI layers its authorities: a tightly guarded, usually offline root CA signs intermediate (subordinate) CAs, which in turn sign end-entity certificates. A relying party trusts a certificate by validating the chain up to a root already in its trust store. The layering means a root compromise stays rare and an intermediate can be revoked without reissuing every certificate beneath it.

Trap Assuming the root CA directly signs end-entity certificates, when it signs intermediate CAs and stays offline so a compromise can be contained at the intermediate level.

A valid certificate must chain to a trusted root, be unexpired, and not be revoked

A verifying signature alone is not enough; a certificate is trustworthy only if all three hold: it chains to a trusted root, has not expired, and has not been revoked. Because a private key can be lost or stolen before expiry, revocation checking is mandatory, not optional. A self-signed certificate fails the first condition and should not be accepted as proof of identity.

Trap Accepting a certificate because its signature verifies, while ignoring that it is expired, self-signed, or revoked.

Use OCSP for real-time revocation; a CRL is the periodic-download fallback

A Certificate Revocation List (CRL) is a CA-signed list of revoked serial numbers that clients download, but it goes stale between publications and grows large at scale. The Online Certificate Status Protocol (OCSP) answers the status of a single certificate in real time, and OCSP stapling has the server attach a recent signed status so the client need not contact the CA. Choose OCSP when freshness matters.

Trap Picking a CRL when the requirement is real-time revocation status, since a downloaded list goes stale between publications and OCSP answers per certificate.

1 question tests this

A security engineer discovers that certificate revocation checking in their PKI is experiencing significant delays, with some clients not…

Quantum breaks asymmetric crypto but only weakens symmetric and hashing

Shor's algorithm on a large quantum computer efficiently factors integers and solves discrete logs, defeating RSA, ECC, and Diffie-Hellman. Grover's algorithm only roughly halves the effective strength of symmetric ciphers and hashes, which is countered by doubling key or output size, so AES-256 and SHA-384 stay strong. The asymmetric algorithms are the ones that need replacing.

Trap Assuming a quantum computer breaks AES and SHA outright, when Grover only halves their strength (fixed by larger sizes) while Shor defeats RSA, ECC, and DH.

2 questions test this

Migrate to NIST post-quantum standards now against harvest-now-decrypt-later

NIST finalized its first post-quantum standards in August 2024: ML-KEM (FIPS 203) for key encapsulation and ML-DSA (FIPS 204) and SLH-DSA (FIPS 205) for signatures. Because adversaries can record encrypted traffic today and decrypt it once quantum computers arrive (the harvest-now-decrypt-later threat), data with a long confidentiality lifetime should adopt these algorithms now rather than waiting for a quantum computer to exist.

Trap Deferring post-quantum migration until quantum computers exist, when harvest-now-decrypt-later means long-lived secrets are already at risk from recorded traffic.

4 questions test this

QKD detects eavesdropping but does not replace authentication

Quantum key distribution (QKD) uses quantum physics rather than math to detect any eavesdropper on a key exchange, but it requires special hardware and provides no source authentication on its own. NIST and NSA guidance therefore favor post-quantum algorithms over QKD for general use. Treating QKD as a drop-in replacement for the whole cryptographic stack is the misconception to avoid.

Trap Assuming QKD by itself replaces authentication or post-quantum algorithms. It only secures key exchange and needs dedicated hardware.

Store passwords with a slow, memory-hard, per-user-salted hash

Fast general-purpose hashes (MD5, SHA-1, SHA-256) are unfit for passwords because GPUs compute billions per second and unsalted ones fall to precomputed rainbow tables. Use a deliberately slow, memory-hard algorithm (Argon2id, bcrypt, scrypt, PBKDF2) with a unique random salt per password. A salt defeats rainbow tables and forces one-at-a-time cracking; a pepper (a secret added via a keyed derivation step and held separately, e.g. in an HSM) adds protection if only the database is stolen.

Trap Salt defeats precomputation (rainbow tables) but does NOT slow brute force. Only a slow/memory-hard function does; both are needed.

8 questions test this

Also tested in

SY0-701 CompTIA Security+

References

NIST glossary: Advanced Encryption Standard (AES) Whitepaper
NIST glossary: digital signature (FIPS 186-5) Whitepaper
NIST glossary: perfect forward secrecy Whitepaper
NIST glossary: message authentication code (MAC) Whitepaper
NIST glossary: cryptoperiod (SP 800-57) Whitepaper
NIST glossary: public key infrastructure (PKI) Whitepaper
NIST: NIST Releases First 3 Finalized Post-Quantum Encryption Standards (FIPS 203/204/205) Whitepaper