🔐 CompTIA Security+ SY0-701 · Domain 1

Cryptography Fundamentals
Symmetric · Asymmetric · Hashing · PKI

Master encryption algorithms, hashing functions, digital signatures, and the PKI trust model — with scenario-based quizzes and an algorithm selector tool built for SY0-701.

🎯 Take the Practice Quiz
Cryptography Fundamentals

Domain 1 (General Security Concepts) is 12% of the SY0-701 exam. Cryptography questions focus on which algorithm to use when and why — understanding the trade-offs between speed, security, and use case.

🔑
The three security goals cryptography serves: Confidentiality = encryption (symmetric or asymmetric). Integrity = hashing (one-way, detects tampering). Non-repudiation = digital signatures (asymmetric + hashing combined). PKI is the trust infrastructure that makes all of this work at scale.
🔑
Symmetric Encryption

One Key, Both Ways

Same key encrypts and decrypts. Fast and efficient — ideal for bulk data encryption. The key distribution problem is the core challenge.

AES: Current standard, 128/192/256-bit 3DES: Legacy, being phased out ChaCha20: Fast stream cipher (mobile) Speed: Fast — used for bulk data
🔐
Asymmetric Encryption

Key Pairs: Public & Private

Different keys for encryption and decryption. Solves key distribution but is computationally slow — used for key exchange and digital signatures, not bulk data.

RSA: Key exchange and digital sigs ECC: Smaller keys, same strength DH/DHE: Key exchange only Speed: Slow — not for bulk data
🔍
Hashing

One-Way Fingerprint

Produces a fixed-length digest from any input. Cannot be reversed. Used to verify integrity — not for confidentiality. A changed file = a different hash.

SHA-256/SHA-3: Current standard MD5/SHA-1: Broken — do not use HMAC: Hash + secret key bcrypt: Password hashing with salt
📜
PKI & Certificates

Trust Infrastructure

Public Key Infrastructure — the system of CAs, certificates, and revocation mechanisms that lets the internet trust asymmetric keys at scale.

CA: Issues and signs certificates X.509: Standard certificate format CRL/OCSP: Revocation mechanisms TLS: Puts it all together

The SY0-701 Cryptography Mindset

The exam rarely asks you to know algorithm internals — it asks you to choose the right tool for the job. Symmetric = fast bulk encryption. Asymmetric = key exchange and signatures (slow). Hashing = integrity, never confidentiality. PKI = how trust is established. Know the purpose and limits of each.

💡
How TLS combines all four: When you visit an HTTPS site, asymmetric crypto authenticates the server (PKI certificate), asymmetric crypto exchanges a session key, then symmetric crypto encrypts the actual data, and hashing (HMAC) verifies each message hasn't been tampered with. All four pillars in one handshake.
Take the Quiz →
Deep Dive: Each Cryptographic Category

The algorithms, attributes, and exam traps for each cryptographic category on SY0-701.

🔑 Symmetric Encryption One Key

AES (Advanced Encryption Standard)
The current gold standard for symmetric encryption. Block cipher operating on 128-bit blocks with 128, 192, or 256-bit key sizes. AES-256 is the highest security tier. Used everywhere: disk encryption, VPNs, TLS session encryption, file encryption.
Block cipher · 128/192/256-bit keys
3DES (Triple DES)
Applies DES three times to each block. Legacy algorithm being phased out — slow and offers effective 112-bit security (not true 168-bit due to meet-in-the-middle attacks). Still found in legacy payment systems. NIST deprecated 3DES in 2023.
Legacy · Being phased out
DES (Data Encryption Standard)
56-bit key — broken. A 56-bit key can be brute-forced in hours with modern hardware. Only relevant on the exam as an example of what NOT to use, or in historical context. Superseded by AES.
56-bit · Broken — do not use
ChaCha20
Modern stream cipher favored for mobile and low-power devices where AES hardware acceleration isn't available. Used in TLS 1.3 paired with Poly1305 for authentication (ChaCha20-Poly1305). Designed by Daniel Bernstein.
Stream cipher · Mobile/TLS 1.3
RC4
Stream cipher — once widely used in WEP and early TLS. Now broken due to statistical biases in its keystream output. Prohibited in TLS since RFC 7465 (2015). Appears on the exam as an example of a deprecated/insecure algorithm.
Stream cipher · Broken — deprecated
Key Distribution Problem
The fundamental challenge of symmetric encryption: both parties need the same secret key, but how do you securely share it over an untrusted network? This is exactly why asymmetric cryptography (Diffie-Hellman) is used for key exchange — so a symmetric key can then be shared safely.
Core limitation
⚠️
Exam trap — modes of operation: AES is a block cipher that needs a mode of operation. ECB (Electronic Code Book) is insecure — identical plaintext blocks produce identical ciphertext blocks. CBC, GCM (authenticated encryption), and CTR are secure modes. GCM is preferred in TLS 1.3 because it provides both confidentiality and integrity.
Exam keyword mapping "Current standard, bulk encryption" = AES · "Legacy, being phased out" = 3DES · "56-bit, broken" = DES · "Mobile devices, TLS 1.3" = ChaCha20 · "Deprecated stream cipher, WEP" = RC4

🔐 Asymmetric Encryption Key Pairs

RSA (Rivest-Shamir-Adleman)
Most widely used asymmetric algorithm. Based on the difficulty of factoring large prime numbers. Supports both encryption and digital signatures. Common key sizes: 2048-bit (minimum) or 4096-bit. Computationally expensive — used for key exchange and signatures, not bulk encryption.
Key exchange + Digital sigs · 2048+ bit
ECC (Elliptic Curve Cryptography)
Achieves the same security as RSA with dramatically smaller key sizes — a 256-bit ECC key is equivalent to a 3072-bit RSA key. More efficient on mobile and IoT devices. Used in ECDSA (digital signatures) and ECDH (key exchange). The direction of travel for modern systems.
Smaller keys · Mobile/IoT · Modern
Diffie-Hellman (DH / DHE / ECDHE)
A key exchange protocol — NOT an encryption algorithm. Allows two parties to establish a shared secret over an insecure channel without ever transmitting the secret itself. DHE (Ephemeral) generates a new key for each session — provides forward secrecy. ECDHE uses elliptic curves for efficiency.
Key exchange only · Forward secrecy
Digital Signatures
Hash the message, then encrypt the hash with your private key. The recipient decrypts with your public key and verifies the hash. Provides: integrity (hash detects changes), authentication (only you have your private key), and non-repudiation (you cannot deny signing it).
Integrity + Auth + Non-repudiation
DSA (Digital Signature Algorithm)
A FIPS standard for digital signatures only — cannot be used for encryption. Based on the discrete logarithm problem. Being superseded by ECDSA (the elliptic curve variant). Appears on the exam as a signature-only algorithm.
Signatures only · FIPS standard
Forward Secrecy (PFS)
If a long-term private key is compromised in the future, past session recordings cannot be decrypted. Achieved by using ephemeral (DHE/ECDHE) key exchange — each session generates a fresh key that is discarded afterward. Required in TLS 1.3. The exam may call it "perfect forward secrecy."
PFS · TLS 1.3 required
⚠️
Critical exam distinction — encryption direction: To send someone an encrypted message: encrypt with their public key (only they can decrypt with their private key). To create a digital signature: sign with your private key (anyone can verify with your public key). Wrong direction = wrong answer on the exam.
💡
Hybrid encryption: In practice, asymmetric is never used to encrypt bulk data. Instead: use asymmetric to encrypt a symmetric session key, then use that symmetric key to encrypt the actual data. This is exactly what TLS does. The exam tests this pattern.

🔍 Hashing Integrity

SHA-256 / SHA-3
Current standard hashing algorithms. SHA-256 (part of the SHA-2 family) produces a 256-bit digest and is used in TLS, certificates, and code signing. SHA-3 is a newer NIST standard with a different internal structure (Keccak sponge). Both are considered secure for current use.
Current standard · Secure
MD5
128-bit digest — collision vulnerabilities discovered in 1996, fully broken by 2004. Collision attacks are trivially fast on modern hardware. Should NEVER be used for security purposes. Still appears in legacy systems and on the exam as an example of a broken algorithm.
128-bit · Broken — collision vulnerable
SHA-1
160-bit digest — theoretical collision attacks known since 2005; practical collision demonstrated by Google's SHAttered attack in 2017. Deprecated for TLS certificates since 2017. Still sometimes used in non-security contexts (git commit IDs) but not acceptable for cryptographic security.
160-bit · Deprecated · Broken
HMAC (Hash-based Message Authentication Code)
A hash computed with a secret key mixed in (e.g., HMAC-SHA256). Provides both integrity and authentication — only someone with the key can produce a valid HMAC. Used in TLS record layer (after key exchange) and API authentication (JWT signatures, AWS Signature v4).
Keyed hash · Integrity + Auth
bcrypt / PBKDF2 / Argon2
Password hashing algorithms — specifically designed to be intentionally slow (computationally expensive) to defeat brute-force and dictionary attacks. Include a random salt to prevent rainbow table attacks. Argon2 won the Password Hashing Competition (2015) and is the current recommendation. NOT used for general-purpose hashing.
Password hashing · Salted · Slow by design
Collision & Pre-image Resistance
Collision resistance: Hard to find two different inputs that produce the same hash (MD5 and SHA-1 fail this). Pre-image resistance: Given a hash, hard to find the original input. Second pre-image resistance: Given an input, hard to find a different input with the same hash. A secure hash must satisfy all three.
Security properties
⚠️
Hashing ≠ encryption. Hashing is one-way — you cannot decrypt a hash. If the exam says "verify integrity" or "detect tampering" → hashing. If it says "recover the original data" → encryption. Hashing provides integrity, not confidentiality. A common exam trap: "the hash was the same so the data was not modified" — that's correct use of hashing for integrity verification.

📜 PKI & Certificates Trust Infrastructure

Certificate Authority (CA)
A trusted third party that issues and digitally signs certificates, binding a public key to an identity. Root CA: the ultimate trust anchor (offline for security). Intermediate CA: issues end-entity certificates on behalf of the root. The chain: Root CA → Intermediate CA → End-entity certificate.
Trust anchor · Issues certificates
X.509 Certificate
The standard format for digital certificates. Contains: subject (who), public key (their key), issuer (who signed it), validity period (not before/not after), serial number, and the CA's digital signature. The CA's signature is what makes the certificate trusted — it proves the CA verified the identity.
Standard format · CA-signed
CRL (Certificate Revocation List)
A list published by the CA of certificates that have been revoked before their expiry date (e.g., due to key compromise or employee departure). Clients download and check the CRL. Limitation: can be large and outdated between publications — real-time checking requires OCSP.
Revocation · Periodic list
OCSP (Online Certificate Status Protocol)
Real-time certificate revocation checking. The client sends the certificate's serial number to an OCSP responder (run by the CA) and receives a signed "good," "revoked," or "unknown" response. OCSP Stapling: the server includes the OCSP response in the TLS handshake, removing the privacy concern of clients querying the CA directly.
Real-time revocation · OCSP Stapling
Certificate Types
DV (Domain Validation): Confirms domain control only — quick, cheap, basic padlock. OV (Organization Validation): Verifies the organization's identity. EV (Extended Validation): Rigorous vetting; formerly showed green address bar. Wildcard: Covers *.domain.com (all subdomains). SAN (Subject Alternative Name): Multiple distinct domains in one cert.
DV / OV / EV / Wildcard / SAN
CSR (Certificate Signing Request)
A file generated by the entity requesting a certificate. Contains the applicant's public key and identity information. Sent to the CA, which verifies the information and returns a signed certificate. The private key NEVER leaves the applicant — the CA only ever sees the public key.
Request to CA · Private key stays local
TLS Handshake — How All Four Pillars Work Together
1
ClientHelloClient sends supported cipher suites and TLS version to server.Negotiation
2
ServerHello + CertificateServer replies with chosen cipher suite and its X.509 certificate (public key + CA signature).PKI
3
Certificate VerificationClient verifies the certificate chain up to a trusted root CA. Checks expiry and revocation (OCSP/CRL).Trust
4
Key ExchangeClient and server use ECDHE (asymmetric) to negotiate a shared session key without transmitting it.Asymmetric
5
Session Encryption BeginsAll subsequent data encrypted with AES (symmetric) using the negotiated session key. HMAC verifies each record.Symmetric + HMAC
💡
Certificate pinning: An application hard-codes an expected certificate or public key and rejects any other certificate — even a valid CA-signed one. Prevents man-in-the-middle attacks using rogue CA-issued certificates. Used by mobile apps and high-security services. Downside: certificate rotation requires an app update.
Side-by-Side Comparison

Filter by category or view all. The exam tests your ability to select the right cryptographic tool — mastering the differences is the key to full-credit scenario answers.

Criterion 🔑 Symmetric 🔐 Asymmetric 🔍 Hashing 📜 PKI
Primary Purpose Confidentiality — bulk data encryption with speed Key exchange, digital signatures, and small-data encryption Integrity verification — detect tampering, no confidentiality Trust infrastructure — bind identities to public keys at scale
Key Type Single shared secret key (both parties must have it) Key pair: public key (shared openly) + private key (never shared) No key (or optional secret key for HMAC) Asymmetric key pair + CA-signed certificate binding
Reversible? ✅ Yes — decrypt with the same key ✅ Yes — decrypt with private key (or public, depending on direction) ❌ No — one-way function, cannot decrypt ✅ Yes (encryption) / ❌ No (certificate signatures are one-way verification)
Speed ⚡ Fast — hardware-accelerated AES 🐌 Slow — computationally expensive ⚡ Very fast Variable — depends on underlying asymmetric operations
Current Algorithms AES-128/256, ChaCha20 RSA-2048+, ECC (ECDSA/ECDHE), DHE SHA-256, SHA-3, HMAC-SHA256, bcrypt/Argon2 (passwords) X.509 v3, RSA or ECC key pairs, SHA-256 signatures
Broken/Deprecated DES (56-bit), 3DES (phasing out), RC4 (stream, broken) RSA <1024-bit (broken), DSA with weak parameters MD5 (collision broken), SHA-1 (deprecated 2017) SHA-1 signed certs (revoked), self-signed certs (untrusted)
Security Goals Confidentiality only Confidentiality + Authentication + Non-repudiation Integrity only (+ Authentication with HMAC) Authentication + Integrity (enables all CIA triad via TLS)
Exam Keyword "Fast bulk encryption," "shared key," "AES" = Symmetric "Key exchange," "non-repudiation," "digital signature," "ECC" = Asymmetric "Integrity," "detect tampering," "one-way," "password storage" = Hashing "Certificate," "CA," "revocation," "trust chain," "TLS" = PKI
Exam-Style Vignettes

Read each scenario and identify the correct cryptographic answer before checking the breakdown.

🔑 SymmetricProtecting Data at Rest
"A healthcare organization needs to encrypt 10TB of patient records stored on their on-premises SAN. The solution must be fast enough to not impact database read/write performance. What encryption standard should they use?"
Correct AnswerAES-256 — the current standard for symmetric encryption; hardware-accelerated on modern CPUs, fast enough for bulk data at rest
Why Not RSA?Asymmetric encryption (RSA) is orders of magnitude slower — completely impractical for 10TB of data
Why Not SHA-256?SHA-256 is a hash function — one-way, provides integrity not confidentiality; cannot encrypt/decrypt data
Exam Key"Large volume of data," "performance," "encrypt storage" → AES (symmetric)
🔍 HashingDetecting File Tampering
"A software vendor publishes a SHA-256 hash alongside each software download. After downloading a new security patch, the IT administrator wants to verify the file was not corrupted or tampered with during transfer before deploying it to 500 endpoints."
ProcessCompute SHA-256 hash of the downloaded file → compare to the vendor's published hash. If identical, the file has not been modified.
Security GoalIntegrity verification — not confidentiality. The file is public; the goal is to detect corruption or tampering.
Why SHA-256 Not MD5?MD5 is broken — collision attacks allow an attacker to create a malicious file with the same MD5 hash as the legitimate file. SHA-256 is collision-resistant.
Exam Key"Verify file integrity," "detect tampering," "check download" → Hashing (SHA-256)
🔐 AsymmetricNon-Repudiation via Digital Signature
"A financial services company needs to ensure that when a trader submits a large transaction, the trader cannot later deny having submitted it. Which cryptographic mechanism provides non-repudiation, and how does it work?"
MechanismDigital signature — the trader signs the transaction with their private key. Anyone can verify with the trader's public key, but only the trader has the private key, so they cannot deny signing it.
How It WorksHash the transaction → encrypt the hash with trader's private key → attach as signature. Recipient: decrypt with trader's public key → rehash transaction → compare hashes.
Security Goals AchievedNon-repudiation (can't deny) + Integrity (hash detects changes) + Authentication (private key proves identity)
Exam Key"Cannot deny," "prove who sent it," "non-repudiation" → Digital signature (asymmetric private key)
📜 PKICertificate Revocation
"A company's web server private key was compromised after an intrusion. The certificate is valid for another 18 months. The security team needs to immediately invalidate the certificate so browsers no longer trust it. What must they do?"
Correct ActionRequest certificate revocation from the CA — the CA will add the certificate to the CRL and update the OCSP responder. Browsers checking revocation will see it as "revoked."
CRL vs. OCSPCRL is a published list (updated periodically). OCSP provides real-time status. OCSP Stapling lets the server include the revocation proof in the TLS handshake.
Why Not Just Wait?The cert is valid 18 more months — attackers could use the compromised private key to impersonate the site for that entire period. Revocation is urgent.
Exam Key"Compromised private key," "invalidate certificate," "revoke before expiry" → CRL / OCSP revocation
⚠️
Top 5 exam traps: (1) Hashing ≠ encryption — hashing is one-way, provides integrity not confidentiality. (2) Encrypt to send confidentially: use recipient's public key. Sign for non-repudiation: use your private key. (3) MD5 and SHA-1 are broken — SHA-256 is current. (4) DH/DHE is key exchange only — not encryption. (5) ECC provides the same strength as RSA with a much smaller key size.
Practice Quiz

10 scenario-based questions with per-category breakdown — built around actual SY0-701 scenario question patterns.

Question 1 of 10

Symmetric
—
Asymmetric
—
Hashing
—
PKI
—
Algorithm Selector Tool

Answer 2–3 questions to identify the most appropriate cryptographic approach for your scenario.

What cryptographic goal are you trying to achieve?
Think about the security property you need — not the specific algorithm.
What are you encrypting?
Does the verification need a shared secret (authentication), or just a public checksum?
What are you signing?
What kind of authentication?
Memory Hooks & Mnemonics

Click each card to flip it and reveal the mnemonic.

👆 Tap a card to flip

🔑
Symmetric
When do you use symmetric encryption?
"Same key, speed, and scale."
Symmetric = one shared key, fast, used for bulk data. AES is the standard. Problem: how do you share the key safely? That's what asymmetric (DH) solves.
🔐
Asymmetric Keys
Public key encrypts or verifies? Private key does what?
Public: lock it. Private: open it (or sign it).
Encrypt to someone: use their PUBLIC key (only they can decrypt). Create a digital signature: use YOUR PRIVATE key (anyone can verify). Wrong direction = wrong exam answer.
🔍
Hashing
Is hashing encryption? Can you decrypt a hash?
Hashing = fingerprint, not a safe.
One-way only — no key, no decrypt.
Hashing = integrity only. Cannot recover data from a hash. MD5 and SHA-1 are broken. SHA-256 is current. bcrypt/Argon2 for passwords (add salt, go slow).
📜
PKI / Certificates
What does a CA actually do?
"The CA vouches for the key."
A certificate = public key + CA signature. The CA's signature says "I verified this identity owns this key." Your browser trusts the CA → trusts the cert → trusts the connection. Root CA → Intermediate → End-entity.
🐌
Asymmetric Speed
Why isn't asymmetric used to encrypt files?
Asymmetric is slow. Use it only for keys and signatures — never bulk data.
Hybrid encryption: use asymmetric (ECDHE) to exchange a symmetric key, then use AES to encrypt the actual data. TLS does exactly this — asymmetric for handshake, symmetric for data.
🪙
ECC vs RSA
Why use ECC instead of RSA?
ECC: same strength, smaller keys, less power.
256-bit ECC ≈ 3072-bit RSA in strength. ECC is faster and uses less battery — ideal for mobile, IoT, and TLS 1.3. ECDSA = ECC digital signatures. ECDHE = ECC key exchange with forward secrecy.
🔄
Forward Secrecy
What is perfect forward secrecy and why does it matter?
"Compromise today, can't decrypt yesterday."
DHE/ECDHE generates a fresh session key for every connection — keys are discarded after use. If the server's private key leaks in the future, past recordings of traffic cannot be decrypted. Required in TLS 1.3.
🚫
Revocation
What's the difference between CRL and OCSP?
CRL = list (slow). OCSP = real-time. OCSP Stapling = server proves it.
CRL: download the whole revoked-cert list periodically. OCSP: ask the CA in real time if this cert is valid. OCSP Stapling: server bundles the CA's signed "still valid" response in the TLS handshake — no privacy leak.

SY0-701 Quick-Recall Cheat Sheet

If the exam says…Key detailAnswer
"Bulk encryption," "encrypt large data," "fast"Shared key, one directionAES (Symmetric)
"Legacy symmetric," "being phased out," "payment systems"3× DES, slow, deprecated3DES
"56-bit key," "broken symmetric"Original DES, brute-forceableDES — Broken
"Key exchange," "shared secret without transmitting it"DH/DHE/ECDHE — not encryptionDiffie-Hellman
"Non-repudiation," "cannot deny," "digital signature"Hash + private keyDigital Signature (RSA/ECDSA)
"Same strength, smaller key," "mobile / IoT"256-bit ECC ≈ 3072-bit RSAECC
"Detect tampering," "verify integrity," "one-way"No key, fixed-length outputSHA-256 / SHA-3
"Broken hash," "collision attack"MD5 (128-bit) or SHA-1 (160-bit)MD5 / SHA-1 — Broken
"Password storage," "salt," "resistant to brute-force"Slow by design, saltedbcrypt / Argon2
"Hash with authentication," "API integrity," "TLS record"Keyed hash, shared secretHMAC
"Certificate authority," "trust chain," "CA signs cert"Binds public key to identityPKI / X.509
"Certificate revoked," "invalidate cert early"List-based revocationCRL
"Real-time revocation check," "OCSP Stapling"Live status query to CAOCSP
"Past sessions safe if key compromised later"Ephemeral key exchangePerfect Forward Secrecy (DHE/ECDHE)
🎓 Security+ Exam Prep Platform

Ready to Pass Security+?
Get Everything You Need in One Place.

These concept pages are just the start. FlashGenius gives you a complete Security+ prep toolkit — practice tests, flashcard decks, domain cheat sheets, and scenario quizzes built for SY0-701.

🎯 Practice Tests
🃏 Flashcard Decks
📄 Domain Cheat Sheets
📊 Scenario Quizzes
🧠 Memory Hooks
🔐 All 5 Domains
🚀 Start Free on FlashGenius View All Security+ Resources →
Free to register · No credit card required · Trusted by Security+ candidates