D3 — Cryptographic Attacks & Key Management Lifecycle

Lessons 10 and 13 covered what cryptography and architecture are. This lesson covers how cryptographic systems actually fail — and the CISSP-tested truth that in practice, cryptography rarely fails because the algorithm was broken; it fails because of how the keys around it were managed.

Three attack classes, precisely distinguished

• Brute-force attack — systematically trying every possible key until the correct one is found. Its feasibility is a direct function of key length: each additional bit doubles the search space. This is why key length recommendations exist and change over time as computing power grows — a key length considered infeasible to brute-force today may not remain so indefinitely.
• Known-plaintext attack — the attacker has access to both a plaintext and its corresponding ciphertext (not by choice, but because some plaintext happened to be known or predictable), and uses that pairing to deduce information about the key or algorithm's behavior. This is a structural weakness distinct from brute force: it doesn't require trying every key, it exploits a pattern.
• Birthday attack (collision attack) — exploits the mathematics of collision probability: finding any two inputs producing the same hash output is dramatically easier than finding an input that produces one specific target hash, due to the same probability effect behind the "birthday paradox" (with surprisingly few people in a room, the chance two share a birthday is much higher than the chance someone shares your specific birthday). This is why hash output length matters more than intuition suggests, and why a weakened hash function vulnerable to collisions is dangerous even if no one can predict what the colliding inputs will actually be.

The exam-relevant distinction: these three attacks exploit fundamentally different things — computational exhaustion (brute force), a data pattern the attacker got lucky enough to observe (known-plaintext), and probability mathematics inherent to how hashing works (birthday/collision) — so the correct defense for each is different, and a question describing one specific attack is testing whether you reach for the matching defense, the same layer-matching logic from Lesson 6's network attacks.

Why key length alone doesn't determine strength

A longer key resists brute force better, in isolation. But cryptographic strength in practice depends on the whole system: the algorithm's own mathematical soundness (a flawed algorithm with a long key can still be broken through structural weaknesses, not brute force at all), correct implementation (a theoretically strong algorithm, implemented with a subtle bug, can leak information regardless of key length), and — as the rest of this lesson argues — how the keys themselves are managed throughout their life. A perfect algorithm with a leaked key protects nothing.

The key management lifecycle — where cryptography actually fails

Five stages, and CISSP treats discipline across all five as more operationally significant than algorithm selection:

1. Generation — keys must be generated with sufficient randomness (entropy); a predictable key-generation process undermines even a strong algorithm entirely.
2. Distribution — getting the key securely to who needs it (this is exactly the problem asymmetric encryption exists to solve, per Lesson 10).
3. Storage — keys at rest must themselves be protected (a hardware security module, or at minimum access-controlled and encrypted storage) — a key stored in plaintext next to the data it protects defeats the entire purpose.
4. Rotation — periodically replacing keys limits the impact of an undetected compromise: if a key is rotated regularly, a leaked old key has a bounded window of usefulness to an attacker, rather than an indefinite one.
5. Destruction — when a key is retired, it must be verifiably destroyed (echoing Lesson 8's media sanitization: an improperly destroyed key is functionally equivalent to a leaked one).

The pattern worth internalizing: in real-world incidents, cryptographic failures overwhelmingly trace back to a lifecycle failure — a key generated with weak entropy, stored insecurely, never rotated, or improperly destroyed — far more often than to the underlying algorithm itself being mathematically broken. This is precisely why CISSP weights key management discipline heavily: it's the stage most often actually responsible when "strong encryption" fails in the real world.

The CISSP mindset: manager vs technician

A team migrates from AES-128 to AES-256 encryption for a sensitive database, citing "stronger encryption," while the encryption key itself has never been rotated in over three years and is stored in a plaintext configuration file alongside the application code.

The technician answer: upgrading to a longer key length is a meaningful, measurable improvement — AES-256 is objectively stronger against brute force than AES-128.

The manager (CISSP) answer: the algorithm upgrade addresses a threat (brute force) that isn't the organization's actual weak point. A key stored in plaintext in a configuration file is trivially exposed to anyone with read access to that file — regardless of whether the algorithm protecting the data is AES-128 or AES-256, the practical security of the data is governed by the key's exposure, not its theoretical brute-force resistance. The CISSP-correct priority is fixing key storage and establishing a rotation policy first, because that's where cryptographic systems actually fail in practice — the same misdirected-effort pattern as Lesson 9's clean vulnerability scan being mistaken for proof of readiness: solving a well-defined, measurable problem (key length) while the real, less glamorous risk (key management hygiene) goes unaddressed.