Most people who struggle with CISSP cryptography aren't struggling with the math. They're struggling with the question format. The exam doesn't ask you to derive AES rounds or explain how RSA factoring works. It asks which tool you'd pick for a given scenario, and why. That's a different skill from "knowing cryptography," and it's the one this post is built around.
I'll cover the five topics that show up again and again: symmetric encryption, asymmetric encryption, hashing, digital signatures, and PKI. But the real goal is to get you thinking about crypto the way the exam wants you to — as a toolkit where each tool solves a specific problem.
Start with the goal, not the algorithm
This is the single biggest mindset shift, and it's where most candidates leave points on the table.
When you read a crypto question, your first instinct shouldn't be "which algorithm is strongest?" It should be "what property are we actually trying to achieve?" There are really just three:
- Confidentiality: data can't be read by anyone unauthorized
- Integrity: data hasn't been changed in transit or storage
- Authenticity: data came from who it claims to
Non-repudiation is often treated as a fourth, but it's really integrity plus authenticity applied in a way that the sender can't later deny sending the message.
Once you know the property, the tool almost picks itself. Confidentiality wants encryption. Integrity wants hashing. Authenticity and non-repudiation want digital signatures. Real systems stack these, which is where most exam questions actually live.
One pattern I've noticed: candidates who bomb this domain usually memorized algorithm names without ever internalizing what each one is for. They can tell you AES is symmetric but can't tell you why you'd reach for symmetric over asymmetric in a given scenario. That's the gap the exam exploits over and over.
Symmetric encryption
One key, shared between parties. Same key encrypts and decrypts. That's the whole shape of it, and you probably already knew that.
AES is the one to know cold: 128, 192, or 256-bit keys, all still considered secure. 3DES is legacy at this point and mostly historical. ChaCha20 is the modern stream cipher that shows up in TLS 1.3 and mobile. If plain DES appears by itself as an answer, it's wrong.
The real exam angle isn't the algorithms, though. It's the modes of operation. ECB (Electronic Code Book) looks fine in a list of options but is insecure for patterned data. There's a well-known "ECB penguin" image that makes this obvious if you haven't seen it. CBC is fine with random IVs. GCM is the modern preferred answer because it gives you confidentiality and integrity in a single pass (authenticated encryption). When a question lists ECB alongside CBC or GCM, it's testing whether you'll catch the trap.
The interesting problem with symmetric crypto isn't the encryption itself. It's how two parties agree on a key without an attacker seeing it. That's the key distribution problem, and the answer to it is asymmetric.
Asymmetric encryption
Two keys, mathematically related but not derivable from each other. One is public and shared freely. One is private and stays secret. Encrypt with one, decrypt with the other.
RSA (2048 or 4096-bit) is the workhorse most people know. ECC gives you equivalent security at much shorter key lengths, which is why it dominates mobile and IoT. Diffie-Hellman is specifically for key exchange, not message encryption, and that distinction trips people up regularly.
Here's the critical fact for the exam: asymmetric is slow. Orders of magnitude slower than symmetric. You do not encrypt gigabytes of data with RSA. Instead, real systems use asymmetric to securely exchange a symmetric key, then use symmetric for the actual data. That construction is called a digital envelope and it's the most important pattern in applied cryptography:
- Generate a random symmetric session key
- Encrypt the data with that session key (fast)
- Encrypt the session key with the recipient's public key (slow, but the key is tiny)
- Send both
TLS works roughly this way. PGP does too. So does basically every real-world encrypted protocol you'll ever touch. If a question describes someone sending bulk encrypted data to a recipient whose public key they have, and "encrypt it all with the recipient's public key" is one of the options, that's the trap answer. The right answer almost always involves the envelope pattern.
Hashing
A one-way function. Takes input of any length, produces a fixed-length digest. You cannot reverse it to recover the original. That's the whole idea.
Hashing does not give you confidentiality. It gives you integrity. Hash a file, send it, have the recipient hash what they received — if the digests match, the file wasn't modified.
SHA-256 is the default answer for most modern use cases. SHA-3 is newer and built on a different mathematical foundation, which can matter if a question is probing construction details, but it's not a common trap. MD5 and SHA-1 are broken — practical collisions have been demonstrated — and should never be the answer for anything security-sensitive. If you see either in an answer choice for a current-system design question, skip it.
The most common exam trap in this area is password storage. Don't hash passwords with SHA-256 alone. Plain cryptographic hashes are too fast; attackers can test billions of guesses per second against them. For passwords, you want deliberately-slow, memory-hard functions: bcrypt, scrypt, or Argon2. Argon2 is the current recommendation and won the Password Hashing Competition a few years back. When a question describes password storage and SHA-256 appears alongside bcrypt or Argon2, pick the slow one.
Digital signatures
This is the primitive that tends to trip people up because it combines the others.
A valid digital signature proves three things at once: the message came from the claimed sender (authenticity), the message wasn't modified (integrity), and the sender can't plausibly deny sending it (non-repudiation). One mechanism, three properties. That's part of why signatures come up so often on the exam.
The mechanics, without the math:
- Sender computes a hash of the message
- Sender encrypts that hash with their private key. This encrypted hash is the signature.
- Recipient decrypts the signature with the sender's public key, recovering the hash
- Recipient independently hashes the received message
- Matching hashes = valid signature
Notice what's doing the work here. The hash proves integrity. The asymmetric encryption with the private key proves authenticity, because only the sender had that private key. Non-repudiation falls out of authenticity plus integrity combined.
One thing worth flagging because it catches people: digital signatures don't provide confidentiality. The message itself isn't encrypted just because it's signed. If a question asks whether a signing-only system also provides confidentiality, the answer is no.
PKI
Public Key Infrastructure is what makes asymmetric crypto work at internet scale. If I hand you my public key, how do you know it's really mine and not an attacker's key that got swapped in along the way? PKI is how we answer that.
The components you need to know:
- Certificate Authority (CA). The trusted entity that issues certificates. Root of the whole trust model.
- Registration Authority (RA). Handles identity vetting before the CA issues a cert. Sometimes folded into the CA.
- X.509 certificates. The file format. Binds a public key to an identity, signed by a CA.
- Certificate Revocation List (CRL). A periodically-published list of revoked certs. Can be stale.
- Online Certificate Status Protocol (OCSP). A live lookup, one cert at a time.
The CRL vs OCSP distinction shows up constantly. CRL is a list you download periodically. OCSP is a real-time query. OCSP is more timely but introduces a network dependency and some privacy concerns (the CA sees which sites you're checking). CRL is simpler but the information can be days out of date. The "right" answer depends on what the scenario is emphasizing.
The certificate lifecycle goes: entity generates a key pair, submits a CSR (certificate signing request), the RA vets identity, the CA issues a signed certificate, the cert gets used until it expires or is revoked. If it's revoked early, it lands on the CRL or shows up as revoked via OCSP.
Trust chains are the other PKI concept to understand. Your browser doesn't trust every certificate on the internet. It trusts a small set of root CAs baked into the browser's trust store. Those roots sign intermediate CAs, which sign end-entity certificates. Trust flows down the chain. If any link is broken or untrusted, the whole chain fails.
Attacks, at the depth the exam cares about
CISSP tests awareness of attack categories, not detailed attack mechanics. A quick tour will do.
Brute force is trying every possible key, defeated by sufficient key length. Dictionary attacks try common passwords, and salting defeats precomputed dictionaries — which is also what kills rainbow tables (precomputed hash-to-password tables). Birthday attacks exploit collision probability and matter mostly for weakened hash functions.
Man-in-the-middle attacks intercept and potentially modify traffic, and certificate-based authentication is the standard defense. Replay attacks reuse captured authentication data, and nonces or timestamps prevent them. Side-channel attacks exploit physical characteristics like timing, power draw, or electromagnetic emissions, and they mostly matter for implementation security rather than algorithm choice. Chosen-plaintext and chosen-ciphertext attacks give the attacker the ability to pick inputs or outputs, and they're relevant to analyzing algorithm strength.
You don't need to know how any of these work mathematically. You need to recognize the names and the general defense for each.
Where this shows up in real systems
Knowing the primitives is maybe 60% of the battle. The other 40% is recognizing them in systems you already half-know.
TLS uses asymmetric for the handshake and key exchange, symmetric for bulk encryption of the session, hashing for integrity, and digital certificates for server (and sometimes client) authentication. That one protocol touches every primitive on this page. IPsec does something similar at the IP layer for VPN tunnels. SSH does it for remote shell sessions. Full-disk encryption is almost always pure symmetric because speed is everything when you're decrypting a disk in real time. S/MIME and PGP email use digital signatures for authenticity and the envelope pattern for confidentiality. Code signing uses digital signatures to prove publisher identity.
When you see a real-world system in a question, decompose it. What's providing confidentiality? What's providing integrity? What's providing authenticity? The answer is almost always several primitives working together, and the question is usually probing which one is responsible for which property.
How the CISSP exam tests cryptography
If you remember nothing else from this post, remember this decision flow:
- Need confidentiality on bulk data: symmetric encryption
- Need to exchange a key over an insecure channel: asymmetric
- Need to verify data hasn't changed: hashing
- Need to verify sender identity, integrity, and non-repudiation together: digital signature
- Need to verify that a public key really belongs to the claimed owner: PKI
Most CISSP crypto questions can be answered by working backward from the property mentioned in the question stem. Question talks about integrity? Eyes go to hashing or signatures. Mentions bulk data or performance? Symmetric. Asks about exchanging a key? Asymmetric. That matching exercise is the skill the exam is really testing.
Another pattern worth calling out: candidates who feel unsure tend to pick the strongest-sounding option, defaulting to RSA-4096 or AES-256 for everything. The exam isn't usually asking "which specific implementation is strongest." It's asking "which type of crypto fits this scenario." The two answers aren't the same, and the distinction is where easy points are won or lost.
Where to take this next
This post covered the concepts. What actually gets you to a pass is hours of answering use-case questions in the style of the real exam, where you're given a scenario and have to reason your way to the right primitive. That practice is where the tool-picking instinct gets built.
If you want to see where you currently stand, the free CISSP diagnostic in LearnZapp doesn't require a signup. It'll surface which domains are your weakest — and cryptography is a common weak spot even for experienced practitioners, because the exam-style questions don't line up with how most people first learned the topic.
LearnZapp pairs Wiley's CISSP Official Study Guide content with CAT-style adaptive practice. The crypto questions specifically drill the tool-picking skill this post is about, at the difficulty level of the real exam.