If you're preparing for the CompTIA Security+ exam (SY0-701), you've probably already noticed that cryptography is... a lot. It's the topic that makes people's eyes glaze over. There are algorithms with weird names (Twofish? Blowfish?), acronyms everywhere (AES, RSA, ECC, HMAC), and concepts that feel abstract and mathematical.
Here's the good news: cryptography isn't actually that hard. What makes it hard is that it's usually taught in an abstract, intimidating way. Once you strip away the jargon and understand the foundational concepts, it all clicks.
This guide breaks down cryptography the way it should have been explained to you the first time. By the end, you'll understand what cryptography actually does, when to use which tools, and why the exam tests the way it does. No unnecessary math. Just clear explanations and real-world analogies.
Why Cryptography Trips People Up
There are a few reasons cryptography is the stumbling block for Security+ students:
It's abstract. You can't see encryption happening. You can't hold a digital signature. Your brain wants concrete examples, but cryptography lives in the world of math and theory.
It's heavy on names and acronyms. AES, RSA, ECC, SHA-256, HMAC, DES, 3DES, Blowfish, Twofish, Diffie-Hellman, ECC, PKI... the list goes on. When you first encounter them, it feels like you're learning a foreign language.
The exam tests both conceptual understanding AND specific details. You need to understand why symmetric encryption is used for bulk data, and know that AES is the current standard, and remember that DES is deprecated. It's not just "what is encryption?"—it's "which encryption algorithm do you use when, and why?"
Concepts build on each other. You can't understand digital signatures until you understand hashing and asymmetric encryption. You can't understand key exchange until you understand asymmetric encryption. If you miss one building block, everything feels fuzzy.
The good news: all of these are learnable. Once you understand the three core purposes of cryptography and the building blocks, everything else is just applying those concepts.
The Three Things Cryptography Does
All of cryptography—all of it—comes down to three purposes:
1. Confidentiality: Keeping secrets
Encryption scrambles data so that only authorized people can read it. If I send you a file over the internet, I want to make sure that even if someone intercepts it, they can't read it. That's encryption.
2. Integrity: Detecting tampering
Hashing creates a digital fingerprint of data. If someone changes even one bit of the data, the fingerprint changes. I can send you a file and a hash of that file. When you receive it, you compute the hash yourself. If the hashes match, the file wasn't altered. If they don't match, someone tampered with it.
3. Authentication: Proving identity
Digital signatures prove that a message came from who claims to have sent it. It's like signing a check—your signature proves it came from you and (theoretically) nobody else could have made that signature. In cryptography, digital signatures are created with a private key and verified with a public key.
Everything in cryptography serves one (or more) of these three purposes. If you ever feel lost, ask yourself: "Is this about keeping secrets, detecting tampering, or proving who sent this?" That will orient you.
Symmetric Encryption: The Shared Padlock
Imagine you and a friend both want to send each other secret messages. You each buy identical padlocks and give one to the other person. Now whenever you want to send a secret, you put it in a box, lock it with your padlock, and send the box. Your friend can unlock it with their copy of the padlock key (which is identical to yours). You both have the same key. You both can lock and unlock.
That's symmetric encryption in a nutshell. The same key encrypts and decrypts.
Why use symmetric encryption?
- It's fast. Perfect for encrypting large amounts of data.
- It's efficient. You're not doing complicated mathematical operations.
- Used for: file encryption, disk encryption, encrypting data traveling through a VPN, streaming data.
The big problem with symmetric encryption: How do you safely share the key in the first place? If you and your friend are in different cities, you can't just mail the padlock key—someone could intercept it. This is called the key distribution problem, and it was a major headache for cryptography until asymmetric encryption was invented.
Symmetric Encryption Algorithms You Need to Know
AES (Advanced Encryption Standard): This is the modern standard. It comes in three flavors: AES-128, AES-192, and AES-256 (the numbers refer to key length in bits). The longer the key, the more secure. AES-256 is what you'll encounter most often. It's fast, secure, and widely used.
DES (Data Encryption Standard): This is old. Very old. It's insecure by modern standards (key is only 56 bits). The exam will test whether you know DES is deprecated. You won't use it in real life. Don't use it.
3DES (Triple DES): An attempt to patch DES by applying it three times. It's better than DES but still slow and outdated. It's being phased out. Know that it's deprecated but better than DES.
Blowfish and Twofish: Smaller, specialty algorithms. Blowfish has a 64-bit block size (small by modern standards). Twofish is an improvement. They're used in specific applications but not as commonly as AES. Know they exist, but AES is the standard.
What the exam tests: Which algorithm is secure (AES), which are outdated (DES, 3DES), and that symmetric encryption is used for bulk data because it's fast.
Asymmetric Encryption: The Mailbox Model
Now imagine a mailbox on your front door. Anyone can walk up and drop mail into the mailbox (through the slot in the front). But only you have the key to open the mailbox from the back and retrieve your mail.
The mailbox slot is like a public key—anyone can use it. Your mailbox key is like a private key—only you have it. This is asymmetric encryption: two different keys, one public and one private.
How it works:
- You publish your public key (like putting a sign up that says "drop mail in my mailbox").
- Anyone who wants to send you a secret encrypts it with your public key.
- You decrypt it with your private key, which only you have.
Nobody else can decrypt it because they don't have your private key.
Why use asymmetric encryption?
- It solves the key distribution problem. You can publish your public key everywhere—it's public. You don't need to securely share it.
- Used for: key exchange (securely agreeing on a symmetric key), digital signatures, initial setup of secure connections.
The downside: It's slow. Really slow compared to symmetric encryption. Asymmetric encryption involves complex math operations. It's impractical for encrypting large amounts of data.
Asymmetric Encryption Algorithms You Need to Know
RSA (Rivest-Shamir-Adleman): The classic. It's been around since 1977 and is still the most widely used. Keys are typically 2048 bits or longer (longer is more secure). RSA is used for key exchange and digital signatures. Know that 2048-bit RSA is considered secure, and smaller keys are deprecated.
ECC (Elliptic Curve Cryptography): The modern alternative to RSA. It achieves the same security with much smaller keys (256-bit ECC provides security equivalent to 2048-bit RSA). It's faster and more efficient. You'll see it increasingly in modern systems. Know that ECC is the newer, more efficient option.
Diffie-Hellman: This isn't exactly encryption—it's a key exchange algorithm. Two parties who've never met before can use Diffie-Hellman to agree on a shared secret key over an insecure channel. It's conceptually elegant. We'll come back to this.
What the exam tests: RSA is the standard and uses large keys (2048+ bits), ECC is newer and more efficient, and you understand that asymmetric encryption is slower than symmetric so it's used for key exchange rather than bulk encryption.
Symmetric vs. Asymmetric: Using Them Together
Here's the important part: in real-world systems, you don't choose one or the other. You use both together.
Here's how HTTPS/TLS works (this is the most important practical example):
- Your browser connects to a website (asymmetric time).
- The website sends you its public key (RSA or ECC).
- Your browser generates a random symmetric key.
- Your browser encrypts that symmetric key with the website's public key and sends it to the website.
- The website decrypts it with its private key. Now both of you share a symmetric key.
- From that point on, all communication is encrypted with that symmetric key (fast and efficient).
Why this hybrid approach?
- Asymmetric encryption is secure but slow. It's only used once, to exchange a symmetric key.
- Symmetric encryption is fast and efficient. Once you've securely agreed on a key, you use it for all the data.
This is genuinely important to understand because the exam tests it: you understand that asymmetric encryption solves the key distribution problem, and that in practice, systems use asymmetric to set up symmetric keys, then use symmetric for the actual data.
Hashing: The One-Way Function
Here's a function that's easier to understand than it sounds: hashing.
A hash function takes any input (a file, a password, a message—doesn't matter how big) and produces a fixed-length output called a hash digest. For example:
- If you hash the word "password," you might get:
5f4dcc3b5aa765d61d8327deb882cf99 - If you hash the entire Harry Potter series, you'll get an output roughly the same length.
The magic property: it's one-way. You cannot reverse a hash. You cannot look at 5f4dcc3b5aa765d61d8327deb882cf99 and figure out what the original input was.
Another magic property: it's deterministic. The same input always produces the same output. Hash "password" a million times and you'll get 5f4dcc3b5aa765d61d8327deb882cf99 every time.
Why is this useful?
Use case 1: Verifying file integrity
I send you a document and a hash of that document. When you receive them, you compute the hash of the document yourself. If your hash matches the hash I sent, you know:
- The document wasn't corrupted during transmission.
- Nobody altered the document (because even changing one bit changes the hash completely).
Use case 2: Storing passwords securely
A website doesn't store your password in plaintext. That would be insane. Instead, they store the hash of your password. When you log in, they hash what you typed and compare it to the stored hash. If they match, you're in. If someone hacks the database, they get hashes, not passwords. And because hashing is one-way, they can't reverse-engineer the passwords.
(There's a caveat: if passwords are weak, attackers can use precomputed hash tables or dictionary attacks. But that's beyond the scope here.)
Use case 3: Digital signatures
We'll get to this next, but digital signatures rely on hashing.
Hashing Algorithms You Need to Know
SHA-256 (Secure Hash Algorithm 256-bit): The current standard. It produces a 256-bit hash. It's secure and widely used. When the exam mentions "use a modern hash algorithm," it means SHA-256 or something equally strong.
SHA-1: It's old. It's not completely broken, but it has weaknesses and is being phased out. The exam will test whether you know it's deprecated.
MD5 (Message Digest 5): Don't use this for security purposes. It's cryptographically broken. The exam might ask whether you'd use MD5, and the answer is "no, use SHA-256."
The critical property: collision resistance
A collision is when two different inputs produce the same hash. For a hash algorithm to be secure, collisions should be practically impossible. MD5 has known collisions. SHA-1 is theoretically vulnerable to collision attacks. SHA-256 is considered collision-resistant.
What the exam tests: SHA-256 is the standard, SHA-1 is deprecated, MD5 is broken, and you understand that hashing detects whether data has been tampered with.
Digital Signatures: Proving It Was You
Here's where things get interesting. A digital signature combines hashing and asymmetric encryption to prove:
- Who sent a message (authentication)
- The message wasn't altered (integrity)
- The sender can't deny they sent it (non-repudiation)
How it works:
- I write a message.
- I compute a hash of that message (this is the fingerprint).
- I encrypt that hash with my private key. This encrypted hash is the digital signature.
- I send you the message and the digital signature.
- You decrypt the digital signature with my public key to get the hash.
- You compute the hash of the message you received.
- You compare the two hashes. If they match, you know:
- The message came from me (only my private key could have created that signature).
- The message wasn't altered (if it was, the hash would be different).
- I can't deny I sent it (my digital signature proves I did).
Why not just encrypt the whole message with the private key?
Two reasons: (1) asymmetric encryption is slow. Hashing first, then signing the hash, is much faster. (2) The goal isn't secrecy—it's proof of identity and integrity. Digital signatures don't hide the message; they prove who sent it.
Real-world example: Email signing. If I digitally sign an email, you can verify it came from me and that I didn't accidentally change it in transit. You don't need my private key; you use my public key to verify.
What the exam tests: You understand the purpose of digital signatures (authentication, integrity, non-repudiation), the concept of signing with a private key and verifying with a public key, and that they're used with hashing.
HMAC: Hashing with a Secret Key
Here's a variation that combines hashing with symmetric cryptography: HMAC (Hash-based Message Authentication Code).
Regular hashing: anyone can compute the hash. It's great for detecting accidental corruption, but it doesn't prove who computed it.
HMAC: you hash the message using a secret key that both parties share. Now the hash proves not just that the data wasn't altered, but that it came from someone who knows the secret key.
Think of it like this: regular hashing is putting a lock on a box that anyone can open and verify was locked. HMAC is putting a lock on the box that only people with the secret key can verify was locked correctly.
When to use HMAC:
- When both parties share a secret key.
- When you need to verify both integrity and authenticity.
- VPNs often use HMAC to verify that VPN packets haven't been tampered with and actually came from the other endpoint.
What the exam tests: HMAC combines a hash with a shared secret key for both integrity and authenticity verification.
Key Exchange: The Diffie-Hellman Problem Solved
We touched on this earlier: how do two people agree on a shared secret key if they have to communicate over an insecure channel?
Enter Diffie-Hellman key exchange.
The color analogy (the key insight):
Imagine two people, Alice and Bob, who want to agree on a secret color but can only communicate over a public channel where everyone can see their messages.
- Alice picks a secret color (say, blue) and mixes it with a public color (yellow) to create blue-yellow.
- Bob picks a secret color (red) and mixes it with the same public color (yellow) to create red-yellow.
- Alice publicly shares her mixture (blue-yellow). Bob publicly shares his mixture (red-yellow).
- Alice takes Bob's public mixture (red-yellow) and mixes it with her secret color (blue) to get blue-red-yellow.
- Bob takes Alice's public mixture (blue-yellow) and mixes it with his secret color (red) to get blue-red-yellow.
Magic: Without sharing their secret colors, they both arrived at the same final color (blue-red-yellow). Everyone watching saw blue-yellow and red-yellow, but nobody can figure out the final shared color without knowing Alice's secret color or Bob's secret color.
In the actual mathematical version, instead of colors and mixing, it uses exponentials and modular arithmetic. But the concept is identical.
Why this matters: It's elegant. Two parties who've never communicated before can securely agree on a shared secret key over a public channel. No one else, even if they see all the messages, can figure out what the shared secret is.
Real-world use: VPNs use Diffie-Hellman (or related algorithms) to establish a secure tunnel. Two companies that have never met before need to communicate securely. They use Diffie-Hellman to agree on a symmetric key, then encrypt all traffic with that key.
What the exam tests: You understand that Diffie-Hellman allows two parties to agree on a shared secret over an insecure channel, and you understand why this is useful.
Key Length: Why Bigger Is (Generally) Better
One more concept that comes up constantly: key length.
A longer key = more possible combinations = harder to crack by brute force.
- AES-128: 2^128 possible keys. Still considered secure, but smaller than modern recommendations.
- AES-256: 2^256 possible keys. Considered very secure. The standard for sensitive data.
- RSA-2048: 2^2048 possible keys. Considered secure.
- RSA-4096: Even more secure, but slower.
- ECC-256: Equivalent security to RSA-2048, but much smaller key.
A rule of thumb: If an algorithm is modern (AES, SHA-256, RSA-2048+, ECC-256+), it's secure. If you see old recommendations (DES, MD5, RSA-1024), the algorithm is deprecated or broken.
What the exam tests: You know that key length matters, longer keys are more secure, and you understand the baseline minimums (2048-bit RSA, 256-bit AES, etc.).
What the Exam Actually Tests
The CompTIA Security+ exam (SY0-701) is not a math test. It doesn't ask you to compute cryptographic operations. Here's what it actually tests:
Knowing which algorithm for which use case
- When would you use symmetric vs. asymmetric encryption?
- When would you use a hash function?
- When would you use a digital signature?
Knowing symmetric vs. asymmetric at a glance
- Is RSA symmetric or asymmetric? (Asymmetric)
- Is AES symmetric or asymmetric? (Symmetric)
- Is Diffie-Hellman symmetric or asymmetric? (Key exchange, public-key based, but not encryption)
Knowing which hash algorithms are secure vs. deprecated
- Use SHA-256. Avoid SHA-1. Never use MD5 for security.
Understanding digital signatures conceptually
- You sign with your private key, others verify with your public key.
- It proves authentication, integrity, and non-repudiation.
Understanding when to use which
- Use asymmetric for key exchange (how do two parties securely agree on a key?).
- Use symmetric for bulk data (encrypting files, VPN tunnels).
- Use hashing for integrity checking and passwords.
- Use digital signatures for authentication.
Understanding modern algorithms are secure, old ones are not
- AES = good. DES = bad.
- SHA-256 = good. MD5 = bad.
- RSA-2048+ = good. RSA-1024 = bad.
Understanding PKI concepts (covered in detail in other study articles)
- How digital certificates work, certificate authority, certificate revocation, etc.
This is testable, learnable material. There's no hidden complexity. The exam is testing whether you understand concepts and can apply them correctly.
One More Thing: Cryptographic Attacks You Should Know
The exam doesn't go deep into attack methods, but it's good to know what attacks exist so you understand why certain algorithms are deprecated:
- Brute force: Try every possible key. Why longer keys matter.
- Dictionary attack: For passwords, try common words. Why strong passwords matter and why hashing passwords is essential.
- Man-in-the-middle: Someone intercepts communication and impersonates one party. Why authentication (digital signatures, certificates) matters.
- Collision attack: Find two different inputs with the same hash. Why MD5 is broken and SHA-256 is secure.
- Rainbow table: Precomputed hash tables. Why salting passwords matters (beyond the scope of this article, but good to know).
Pulling It All Together
Cryptography isn't magic, and it's not impossibly complex. It's a toolkit for three purposes:
- Keep secrets: Encryption (symmetric for speed, asymmetric for key exchange).
- Detect tampering: Hashing and HMAC.
- Prove identity: Digital signatures (signing with private key, verifying with public key).
Most of cryptography is combining these tools appropriately. Use AES for encrypting files. Use SHA-256 for hashing. Use RSA or ECC for key exchange. Use digital signatures to prove authenticity.
The Security+ exam tests whether you understand these concepts and can apply them. It's not testing whether you can compute a hash by hand or factor large numbers. It's testing whether you understand when to use what and why.
If you've made it this far in this article, you understand more about cryptography than most Security+ candidates. You've got this.
Next Steps: Deepen Your Knowledge
This article covers the conceptual foundations. The Security+ exam also tests specific details: which algorithm parameters are secure, how key management works, how PKI (Public Key Infrastructure) operates, and how cryptographic attacks work.
LearnZapp's Security+ study articles go deeper into each of these areas with targeted, exam-focused content. Our practice questions test whether you can apply these concepts correctly—exactly how the exam tests them.
Take a free Security+ diagnostic test — no signup required to see how well you understand cryptography and identify which areas need more study.
Your Security+ certification is within reach. Cryptography might feel hard now, but with the right explanation and deliberate practice, it clicks faster than you'd expect.
Good luck on your exam.