study-tips

SY0-701 Cryptographic Attacks Explained (Objective 2.4)

By CertQuiz Team|Jul 30, 2026
SY0-701 Cryptographic Attacks Explained (Objective 2.4)

Security+ objective 2.4 asks you to know exactly three cryptographic attacks: downgrade attacks, collision attacks, and birthday attacks. That's a short list, but the exam doesn't reward memorizing three names — it rewards understanding why each attack works and what breaks when it succeeds. This is objective 2.4 inside Domain 2 (Threats, Vulnerabilities, and Mitigations), which carries 22% of the SY0-701 exam — the single heaviest-weighted domain after Security Operations.

Most candidates can define these terms and still miss the scenario questions, because CompTIA doesn't ask "what is a birthday attack" — it gives you a scenario and makes you pick the right term. So this guide skips the flashcard definitions and goes straight to how each attack actually works, with a real incident behind every one. Test what you know right now with our free SY0-701 practice exam — no signup required.

Independent study resource. Not affiliated with or endorsed by CompTIA. Exam codes, objectives, and weightings are set by CompTIA — always confirm current details on official exam pages before booking.

Key Takeaways

  • Objective 2.4 tests exactly three attacks: downgrade, collision, and birthday — all inside Domain 2 (Threats, Vulnerabilities, and Mitigations), 22% of the SY0-701 exam
  • Collision attacks are why MD5 and SHA-1 are considered broken: Google and CWI Amsterdam proved it in 2017 with the "SHAttered" attack — two different PDFs sharing one SHA-1 hash
  • Birthday attacks cut the work to find a collision from 2^n to roughly 2^(n/2) — a 128-bit hash only offers about 2^64 of real collision resistance, not 2^128
  • Downgrade attacks have three famous exam-relevant names: POODLE (2014), FREAK (2015), and Logjam (2015) — all forced a "secure" connection down to breakable crypto
  • TLS 1.3 (RFC 8446) closes the downgrade loophole with a sentinel value baked into the handshake itself, not just a policy telling clients to refuse old versions

Where Objective 2.4 Sits in the SY0-701 Exam

SY0-701 spreads its content across five domains, and Domain 2 — Threats, Vulnerabilities, and Mitigations — is the second-heaviest at 22% of the exam. Objective 2.4, "Analyze indicators of malicious activity" in the cryptographic-attack context, is where CompTIA tests whether you understand why a hash function or a protocol handshake can be broken, not just that it can.

DomainWeightKey Topics
1. General Security Concepts12%Controls, cryptography basics, authentication types
2. Threats, Vulnerabilities & Mitigations22%Malware, social engineering, attack vectors, cryptographic attacks
3. Security Architecture18%Network security, cloud, infrastructure
4. Security Operations28%Incident response, digital forensics, identity
5. Security Program Management20%Governance, risk, compliance, data privacy

Domain weights are per CompTIA's official SY0-701 exam page. The exam runs up to 90 questions in 90 minutes with a passing score of 750 on a 100–900 scale.

Here's the thing that trips people up: objective 2.4 isn't really three unrelated flashcards. Downgrade attacks target the negotiation between two systems, while collision and birthday attacks target the math inside a hash function. Once you separate those two categories, the exam questions stop feeling like a guessing game.

Collision Attacks: When Two Different Things Look Identical

A collision attack finds two different inputs that produce the exact same hash output — a direct violation of what a hash function is supposed to guarantee. In theory, changing one byte of a file should scramble its hash beyond recognition. In practice, older algorithms like MD5 and SHA-1 don't hold up that promise anymore.

This isn't a hypothetical exam scenario. On February 23, 2017, researchers from Google and CWI Amsterdam published "SHAttered" — the first public collision for full SHA-1. They produced two completely different PDF files that share one SHA-1 hash, using roughly $110,000 of cloud compute and the equivalent of 2^63.1 SHA-1 compressions. That single proof-of-concept ended the industry debate about whether SHA-1 was still safe to trust.

Why does this matter beyond the history lesson? SHA-1 and MD5 still show up in legacy digital signatures, Git object hashing, and old file-integrity checks. If an attacker can craft a malicious file with the same hash as a legitimate one, a system that trusts "matching hash = matching file" gets fooled. On the exam, if a question mentions two different files producing an identical checksum, that's a collision attack — not a birthday attack, even though the two are related.

SHAttered attack details per shattered.io (the official research disclosure site run by Google and CWI Amsterdam) and NIST CSRC's 2017 research note on the SHA-1 collision.

Birthday Attacks: Why Collisions Happen Faster Than You'd Think

A birthday attack doesn't target a specific hash — it targets the math behind any hash function, using a quirk of probability called the birthday paradox. Put 23 random people in a room and there's roughly a 50% chance two of them share a birthday. That's wildly higher than most people's intuition, which anchors on "365 days, so I'd need close to 183 people."

Hash functions behave the same way. Finding any two inputs that collide takes roughly 2^(n/2) attempts for an n-bit hash — not the full 2^n you'd expect from brute force. That halves the exponent, which sounds small until you run the numbers. A 128-bit hash offers full 2^128 resistance against someone trying to reverse one specific hash, but only about 2^64 resistance against someone just looking for any collision at all. 2^64 is a number modern hardware can actually approach; 2^128 is not.

This is exactly why the industry moved to 256-bit hash algorithms like SHA-256. A 256-bit hash still gives you roughly 2^128 of birthday-attack resistance — solidly out of reach with current computing power. On the exam, look for the word "any" versus "a specific" — a birthday attack is about finding any matching pair, which is what makes it faster than brute force.

The collision-resistance-halves-to-L/2-bits relationship (the formal basis for the 2^(n/2) birthday bound) is documented in NIST SP 800-107 Rev. 1, "Recommendation for Applications Using Approved Hash Algorithms."

Downgrade Attacks: Forcing a Fallback to Weaker Crypto

A downgrade attack works differently from the other two — it doesn't attack the math at all. It attacks the negotiation that happens before encryption even starts. Most protocols support multiple versions for backward compatibility, and a downgrade attack tricks two systems into agreeing on the oldest, weakest version available instead of the strongest one both actually support.

Three real incidents put this on the map for TLS specifically. In October 2014, POODLE exploited SSL 3.0's padding scheme, letting an attacker decrypt roughly one byte of ciphertext per 256 requests once a connection had been forced down to SSL 3.0. In March 2015, FREAK forced clients into 1990s-era "export-grade" 512-bit RSA keys — weak enough to factor with rented cloud compute. Two months later, Logjam did the same thing to Diffie-Hellman key exchange, forcing connections down to breakable 512-bit parameters. All three depended on one thing: a client or server willing to fall back to a legacy option instead of refusing the connection.

TLS 1.3 closed this loophole structurally, not just with a warning label. Per RFC 8446 section 4.1.3, a TLS 1.3-capable server that ends up negotiating TLS 1.2 or earlier must set the last 8 bytes of its ServerHello random value to a fixed sentinel. A TLS 1.3 client checks for that sentinel on every handshake and aborts if it appears without a legitimate reason — turning a silent fallback into a detectable, rejected downgrade.

POODLE is documented in the original disclosure paper, "This POODLE Bites: Exploiting the SSL 3.0 Fallback" (Möller, Duong, Kotowicz, Google Security Team, Oct 2014). FREAK and Logjam are documented on their respective research disclosure sites, freakattack.com and weakdh.org. TLS 1.3's downgrade-protection sentinel value is specified in RFC 8446, section 4.1.3 (IETF, August 2018).

Cryptographic Attacks: Side-by-Side Comparison

AttackTargetsReal-world examplePrimary mitigation
DowngradeProtocol negotiationPOODLE (2014), FREAK / Logjam (2015)Disable legacy protocol versions; use TLS 1.3's downgrade sentinel
CollisionHash function outputSHAttered SHA-1 collision (2017)Use SHA-256 / SHA-3 instead of MD5 or SHA-1
BirthdayHash function probability spaceSHA-1's 160-bit output only offered ~2^80 birthday-bound resistance — one reason SHAttered was computationally reachableUse hash lengths ≥256 bits for real collision resistance

Notice the pattern: mitigation for all three comes down to the same habit — stop trusting old algorithms and old protocol versions just because a system still technically supports them. That's also a recurring theme across Domain 2 as a whole, not just objective 2.4.

What to Actually Check For (Not Just Memorize)

If you're auditing a real environment — or answering a performance-based question that simulates one — objective 2.4 maps to concrete things you can check. Here's what a working engineer actually looks for, not just the vocabulary list.

  • Hash algorithm in use: grep configs and code for MD5 or SHA-1 in anything security-relevant — password storage, digital signatures, TLS certificate signing. Flag it for migration to SHA-256 or better.
  • Protocol version floors: confirm servers reject SSL 3.0, TLS 1.0, and TLS 1.1 outright rather than merely "preferring" newer versions. A server that still accepts an old handshake is still downgradable.
  • Cipher suite exports: export-grade ciphers (the root cause of both FREAK and Logjam) should not appear anywhere in an active cipher suite list, even as a fallback option.
  • Certificate signing algorithm: check whether certificates in your chain still use SHA-1 signatures — most major browsers stopped trusting SHA-1 certificates years ago, but internal/self-signed chains sometimes still use them.

None of this requires exotic tooling. It's the same checklist a junior security analyst runs during a routine configuration review — which is exactly the kind of real-world tie-in objective 2.4 is testing your judgment on, not just your memory.

How This Shows Up in Exam Scenarios

CompTIA rarely asks "define a birthday attack" directly. Instead, expect a scenario: a pentester reports finding two files with matching MD5 hashes but different contents — that's a collision attack. A security analyst notices a client connection unexpectedly fell back to TLS 1.0 during a man-in-the-middle test — that's a downgrade attack. An auditor flags that a legacy system still hashes passwords with SHA-1 — that's a vulnerability a collision attack could exploit.

Rhetorical question worth asking yourself while you study: could you tell a collision attack from a birthday attack if the question only gave you one sentence of context? If not, go back to the "any pair" versus "specific pair" distinction above — it's the single detail that separates the two on most practice exams. Ready to check? Run through a full set of scenario questions on our free SY0-701 practice exam and see how objective 2.4 questions are actually phrased.

FAQ

Is a birthday attack the same as a collision attack?

No, though they're related. A collision attack is the goal — finding two inputs with the same hash. A birthday attack is the method: using birthday-paradox probability to find that collision in roughly 2^(n/2) attempts instead of 2^n. SY0-701 tests both as separate objective 2.4 terms.

Why is SHA-1 still relevant if it's broken?

Legacy systems — old Git repositories, aging digital signature schemes, and some file-integrity tools — still default to SHA-1 or MD5. The 2017 SHAttered attack proved real-world SHA-1 collisions are achievable for around $110,000 in cloud compute, which is why CompTIA expects you to recommend SHA-256 or SHA-3 instead.

Does TLS 1.3 make downgrade attacks impossible?

It makes silent, undetected downgrades far harder. RFC 8446 requires TLS 1.3 servers to signal a fallback to TLS 1.2 or earlier using a sentinel value in the handshake, which a TLS 1.3 client checks and rejects if unwarranted. Systems still running only TLS 1.0/1.1 without any TLS 1.3 support remain vulnerable to the older attacks like POODLE.

What hash length should I recommend to resist birthday attacks?

256 bits or longer. A 256-bit hash gives roughly 2^128 of birthday-attack resistance, which is well beyond what's practical to brute-force with current computing power. This is why SHA-256 replaced SHA-1 as the default across TLS certificates, code signing, and password hashing pipelines.

Are downgrade, collision, and birthday attacks their own exam domain?

No — all three live inside objective 2.4, part of Domain 2 (Threats, Vulnerabilities, and Mitigations), which is 22% of the SY0-701 exam. Domain 2 also covers malware types, social engineering, and general attack vectors, so cryptographic attacks are one slice of a bigger domain.

Practice What You Just Learned

Reading about objective 2.4 is step one — recognizing it inside a scenario question under time pressure is the actual skill the exam tests. Our free SY0-701 practice exam covers all five domains with detailed answer explanations for every question, including why the wrong options are wrong. No account, no credit card, and your results never leave your browser.

Already have your own SY0-701 question bank? Upload your VCE or PDF to our free simulator and run through it instantly. Or browse more certification study guides covering Security+, CySA+, AWS, and Azure certification paths.

Related reading

security+sy0-701cryptographyexam-objectivesstudy-guide2026

Ready to Practice?

Try our free exam simulator. No signup, no paywall, 100% private.

Take Security+ QuizUpload Your VCE/PDF

We use cookies for analytics (and ads if/when AdSense is enabled). By accepting, you allow these uses. See our Privacy Policy and Cookie Policy.