Cryptography is the topic most Security+ candidates tell me they're worried about. Not firewalls, not access control, not even risk management. Cryptography. And usually not because the concepts are actually hard — because the way it gets taught makes it sound harder than it is.
If you're studying for SY0-701 and you feel fine on most topics but your brain shuts off the moment someone says "asymmetric key exchange," this guide is for you. We're going to strip the math out and explain what cryptography actually does, which algorithms matter, and what the exam is really testing for under the surface.
One thing upfront: the Security+ exam doesn't care whether you can compute a hash by hand. It cares whether you know when to use which tool. Keep that in mind as you read.
Why this topic feels harder than it is
A lot of the difficulty is surface-level. You hit a wall of acronyms — AES, RSA, ECC, SHA-256, HMAC, DES, 3DES, Diffie-Hellman — and it feels like memorizing a new language. But most of those acronyms are just names for tools that do one of three things. Once you know the three things, the acronyms slot into place.
The deeper difficulty is that concepts build on each other. You can't understand digital signatures until you understand hashing and asymmetric encryption. You can't understand TLS until you understand both symmetric and asymmetric. Miss a building block early and everything downstream feels fuzzy. I've watched people study cryptography for weeks without ever nailing down the foundations, and they end up with a head full of acronyms and no mental model. Don't be that person. Get the three-pillar model below into your head first, then learn the algorithms.
One pattern worth calling out: people who can recite "AES is 256 bits" but freeze on "your company needs to encrypt nightly database backups — what family of algorithms?" are studying the wrong way. The exam tests application, not recall.
The three things cryptography does
All of it — every algorithm, every protocol, every acronym — exists to do one of three jobs:
- Confidentiality. Keep data secret from people who aren't supposed to see it. This is encryption.
- Integrity. Detect whether data has been changed. This is hashing.
- Authentication. Prove who sent something (and, by extension, that they can't deny sending it). This is digital signatures.
That's the whole game. When you see an unfamiliar cryptographic term on the exam, ask yourself which of these three it serves. If it's confidentiality, it's encryption of some kind. If it's integrity, it's a hash. If it's "prove this came from a specific person," it's a signature. That one habit will answer a surprising number of exam questions.
Some tools hit more than one of the three. HMAC covers integrity and authentication. TLS handles all three. But every tool traces back to this list.
Symmetric encryption
Picture two people who each have identical keys to the same padlock. Either one can lock the box, either one can unlock it. That's symmetric encryption — one shared key, used for both encrypting and decrypting.
It's fast. That's the whole reason it exists and the whole reason we still use it. When you're encrypting a 50GB backup, or every packet flying through a VPN tunnel, or your entire laptop's hard drive, you need something that can chew through data at speed. Symmetric does that.
The catch is the key distribution problem: how do two parties who've never communicated before agree on a shared key without anyone else getting a copy? You can't just email it. Historically this was the hardest problem in cryptography, and asymmetric encryption eventually solved it. Keep that in mind — it's going to matter when we get to TLS.
Algorithms worth knowing:
- AES is the modern standard. Comes in 128, 192, and 256-bit flavors. AES-256 is what you'll see most often in real systems. For the exam, know that AES is the answer whenever a question asks "which modern symmetric algorithm should be used?"
- DES is dead. 56-bit key, broken decades ago. If DES is an answer choice, it's almost always the wrong one.
- 3DES was a patch on DES that applied it three times in a row. Better than DES, but slow and being phased out. Treat it as "know it's deprecated, know why it existed."
- Blowfish and Twofish exist. Know the names. They're rare in exam questions and rare in modern systems.
Notice I spent one line on Blowfish and four on AES. That's intentional — AES is on almost every cryptography question. Blowfish shows up maybe once in a question bank.
Asymmetric encryption
Different model. Instead of one shared key, you have a pair: a public key that anyone can see, and a private key that only you hold. Data encrypted with the public key can only be decrypted with the matching private key. Think of the public key as a mailbox slot anyone can drop a letter into, and the private key as the only key that opens the mailbox.
This solves the key distribution problem. You don't have to sneak a key to anyone. You publish the public one. Anyone can encrypt a message to you, but only you can read it.
So why not just use this for everything? Because it's slow. Asymmetric encryption involves large mathematical operations that take meaningful time for anything beyond small amounts of data. Encrypting a 50GB backup with RSA would be painful. So we use asymmetric for small, critical tasks — setting up connections, signing documents, exchanging keys — and leave the heavy lifting to symmetric.
Two algorithms show up constantly:
RSA — the old reliable. Standard since the 1970s. Key sizes start at 2048 bits for modern use (1024 is deprecated). Used heavily for digital signatures and key exchange.
ECC (elliptic curve cryptography) — the newer, leaner option. A 256-bit ECC key gives you roughly the same security as a 2048-bit RSA key, which is why you see it everywhere in mobile and modern web. Smaller, faster, same strength.
Diffie-Hellman is the odd one here — it's not really encryption, it's a way for two parties to agree on a shared secret. We'll get to it.
How TLS actually uses both
This is the part of cryptography that most exam questions are really testing, even when they don't look like it. If you only understand one thing from this whole post, make it this one.
When your browser connects to a website over HTTPS, roughly this happens:
The browser and the server do a handshake. The server sends its public key (wrapped in a certificate signed by a trusted authority — more on that in a PKI post). The browser uses the server's public key to securely share a small piece of random data. Both sides derive a symmetric session key from that shared data. From that moment on, every byte of the actual conversation — the web pages, the form submissions, the images, the API calls — is encrypted with that symmetric session key.
Why the two-stage dance? Because the two encryption types complement each other. Asymmetric solves the key distribution problem — it's how the two sides agree on a shared secret without ever having met before. Symmetric solves the speed problem — once the shared key is in place, the fast algorithm takes over and handles the bulk traffic.
If you internalize this pattern, you can answer an enormous range of exam questions:
- "A user connects to a banking website. Which type of encryption protects the bulk of the session?" Symmetric.
- "What is used to establish the initial secure channel?" Asymmetric.
- "Why isn't asymmetric encryption used for the entire session?" It's too slow for bulk data.
- "What problem does asymmetric encryption solve that symmetric cannot?" Key distribution.
Same pattern applies to VPN tunnels, SSH connections, and encrypted email. Asymmetric to start, symmetric to run. Get this and you've gotten past the hardest conceptual block in the domain.
Hashing
A hash function takes any input — a word, a file, a 300-page PDF — and spits out a fixed-length string. SHA-256 always produces 256 bits, whether you feed it the letter "a" or the full works of Shakespeare.
Two properties make hashes useful. They're one-way (you can't reverse the hash to get the original) and they're deterministic (the same input always produces the same hash). Change one byte of the input and the output changes completely.
The two use cases you need:
File integrity. Download a file, compute its hash, compare to the hash the source published. If they match, the file wasn't corrupted or tampered with.
Password storage. Websites never store your actual password — they store a hash. When you log in, they hash what you typed and compare. A database breach leaks hashes, not passwords. (In practice, passwords are also salted to defend against precomputed rainbow tables, but that's a separate topic.)
For the exam: SHA-256 is the modern standard. SHA-1 is deprecated because of collision weaknesses. MD5 is broken — do not use it for anything security-related. If a question asks you to pick a hashing algorithm for any purpose, the answer is SHA-256 unless something specifically indicates otherwise.
A collision, by the way, is when two different inputs produce the same hash. Hash functions are only useful if collisions are practically impossible to generate. MD5 collisions can be generated on a laptop. That's why it's broken.
Digital signatures
This is where hashing and asymmetric encryption combine into something more powerful than either alone. A digital signature proves three things at once: who sent the message, that the message wasn't changed in transit, and that the sender can't later deny sending it (non-repudiation).
The mechanics:
- Sender hashes the message.
- Sender encrypts that hash with their private key. The encrypted hash is the signature.
- Sender sends the message and the signature together.
- Receiver decrypts the signature with the sender's public key, which gives them the original hash.
- Receiver hashes the message themselves and compares.
- If the two hashes match, the message is verified — untouched and genuinely from the claimed sender.
Note the direction: signing uses the private key, verifying uses the public key. This trips people up because regular asymmetric encryption works the opposite way (you encrypt with the recipient's public key, they decrypt with their private). Signatures flip the roles because the goal isn't secrecy — it's proof of origin. The only person who could have produced a signature that decrypts correctly with your public key is the person holding the matching private key. That's you.
A common exam trap: questions that ask what a digital signature provides. The answer always includes authentication, integrity, and non-repudiation. It does not include confidentiality — a digitally signed message can still be read by anyone. If you need secrecy too, you encrypt and sign separately.
HMAC
Quick one. Regular hashing proves integrity but not authenticity — anyone can compute a hash, so a matching hash only tells you the data wasn't corrupted, not who sent it.
HMAC fixes that by mixing a shared secret key into the hash. Now the hash proves both that the data is intact and that it came from someone who knew the secret. VPNs use HMAC to confirm that packets genuinely came from the other tunnel endpoint and weren't injected by an attacker along the way.
If a question mentions integrity plus authenticity plus a shared symmetric secret, HMAC is your answer.
Key exchange with Diffie-Hellman
Back to the problem that started the asymmetric story: how do two parties who've never met agree on a shared secret over a channel where everything they send is visible?
The classic way to explain Diffie-Hellman is with paint. Alice and Bob each pick a secret color. They both start with a common public color — say, yellow. Alice mixes yellow with her secret color and sends the result. Bob does the same and sends his. Then each of them takes the other's mixture and adds their own secret color to it. They both end up with the same final color. An eavesdropper who saw every message sent still can't reproduce the final color because they never saw either secret.
In the real math it's modular exponentiation instead of paint mixing, but the mechanic is the same: both sides can compute the shared result, and anyone listening can't.
This is how VPNs, SSH, and modern TLS establish a symmetric key between two parties who've never communicated before. For the exam, know that Diffie-Hellman is a key exchange mechanism, not encryption — it doesn't encrypt a message, it lets two parties agree on a key they'll use with a separate encryption algorithm.
Key length
Short version: longer keys mean more possible values, which means brute force takes longer. AES-256 has 2^256 possible keys, which is a number that's more or less impossible to exhaust with any realistic computing power. AES-128 is still considered secure but less of a margin. RSA keys should be 2048 bits minimum; 1024 is deprecated. ECC achieves equivalent security at much smaller key sizes.
Rule of thumb: AES-128 or higher, RSA-2048 or higher, SHA-256 or higher, ECC-256 or higher. Anything below those thresholds is either outdated or broken. If an exam answer choice lists a smaller size, assume it's probably the wrong answer.
What the exam really tests
If you zoom out, the cryptography section of SY0-701 tests a fairly small number of things across many questions:
- Can you pick the right tool for a use case? (Symmetric for bulk, asymmetric for key exchange, hashing for integrity, signatures for authentication.)
- Can you identify which algorithms are current and which are deprecated? (AES yes, DES no. SHA-256 yes, MD5 no. RSA-2048 yes, RSA-1024 no.)
- Do you understand the direction of keys in digital signatures? (Sign with private, verify with public.)
- Do you understand the hybrid model in TLS/VPN/SSH? (Asymmetric to set up, symmetric to run.)
- Do you know what problem each tool solves? (Asymmetric solved key distribution. Hashing gives you integrity. Signatures add authentication.)
Almost every cryptography question on the exam is some angle on one of those five. You don't need to memorize algorithm internals. You need the mental model.
One more pattern I've noticed: people who do well on this section usually spent time thinking through scenarios, not reviewing flashcards. "Which algorithm would I use to encrypt a database column that needs to be searchable?" and "Why is RSA used for signing code but not for encrypting the code itself?" are the kind of questions that build real understanding. Flashcards tell you AES is a block cipher. Scenarios tell you when to pick it.
Attacks worth being able to name
The exam doesn't go deep on attack methods, but a handful come up often enough that you should recognize them:
Brute force is just trying every possible key. Longer keys defeat it. Dictionary attacks try common passwords — why hashing isn't enough by itself, and why salt matters. Man-in-the-middle attacks intercept and impersonate — why digital signatures and certificate verification exist. Collision attacks find two inputs that produce the same hash — why MD5 is dead. Rainbow tables are precomputed hash-to-password mappings — why salted hashes defeat them.
None of these need deep study. Recognize the name, know which defense it justifies, move on.
If you've worked through all of that, you know enough about cryptography to handle most of what Security+ will throw at you. The remaining work is practice: sitting with scenario-based questions until the pattern-matching becomes instinctive. Knowing AES is symmetric is table stakes. Knowing instantly that "encrypt 200GB of nightly backup tapes" is a symmetric question is what gets you points on exam day.
If you want to find out where your crypto instincts actually are right now, the fastest way is a diagnostic. LearnZapp has a free Security+ diagnostic that takes about 20 minutes, gives you a domain-by-domain breakdown, and doesn't ask for a signup. You'll know within one sitting whether cryptography is where your real gaps are — or whether it's something else that needs the focus.