D3 — Cryptography Fundamentals: Symmetric, Asymmetric, Hashing, PKI

Every domain so far has leaned on infrastructure or process experience you already had. This one doesn't — cryptography theory is rarely absorbed by osmosis from running production systems, which is exactly why it's placed here, deliberately, as this roadmap's first genuine cold-start topic.

Symmetric encryption: one key, both directions

Symmetric encryption uses the same key to encrypt and decrypt. It's fast and efficient for encrypting large volumes of data (bulk file encryption, TLS session data once a connection is established). Its core problem is key distribution: both parties need the same secret key, and getting that key to the other party securely — without anyone intercepting it in transit — is exactly the problem symmetric encryption itself doesn't solve.

Asymmetric encryption: two keys, solving the distribution problem

Asymmetric (public-key) encryption uses a mathematically linked key pair: a public key (freely shareable) and a private key (kept secret, never shared). Data encrypted with the public key can only be decrypted with the corresponding private key. This solves symmetric encryption's key-distribution problem — you can publish your public key openly, and anyone can use it to send you something only your private key can open, with no prior secret exchange needed. The trade-off: asymmetric operations are computationally expensive, far too slow for encrypting bulk data directly.

Why they're combined, not chosen between: real-world systems (TLS is the canonical example) use asymmetric encryption briefly, at the start of a connection, purely to securely exchange a symmetric session key — then switch to fast symmetric encryption for the actual data transfer. Asymmetric crypto solves the distribution problem; symmetric crypto handles the volume. Neither alone is the "better" choice — they solve different halves of the same problem.

Hashing: integrity, not confidentiality — and irreversible by design

A cryptographic hash function takes input of any size and produces a fixed-size output (a "digest"), with three properties that matter here: it's deterministic (same input always produces the same output), one-way (computationally infeasible to reverse the digest back into the original input), and exhibits the avalanche effect (a tiny input change produces a drastically different output).

This is a fundamentally different tool from encryption, not a weaker version of it: hashing exists to verify integrity — confirming data hasn't been altered, by comparing a freshly computed hash against a known-good one — not to protect confidentiality. It's one-way by design: you're never meant to "decrypt" a hash back into its input. This is also why password storage uses hashing (with salting) rather than encryption — the system needs to verify a password matches, not ever recover the original plaintext.

PKI: how you trust a stranger's public key

Asymmetric encryption solves key distribution, but introduces a new question: if anyone can generate a key pair, how do you know a given public key actually belongs to who it claims to? Public Key Infrastructure (PKI) answers this with a chain of trust:

• A Certificate Authority (CA) verifies an entity's identity, then issues a digital certificate binding that entity's identity to their public key, signed with the CA's own private key.
• Anyone who already trusts that CA (because the CA's own certificate is pre-installed as trusted, e.g. in an OS or browser's trust store) can verify the CA's signature on the certificate, and by extension, trust the public key it contains.
• This creates a chain of trust: your certificate is signed by an intermediate CA, whose certificate is signed by a root CA, whose certificate is inherently trusted because it's pre-distributed as a trust anchor. Trust in the whole chain reduces to trust in that root.

A digital signature (an entity signing something with their own private key, verifiable by anyone with their public key) proves two things at once: authenticity (it came from the holder of that private key) and integrity (it hasn't been altered since signing) — the signature itself is essentially a hash of the content, encrypted with the signer's private key.

The CISSP mindset: manager vs technician

An internal tool needs to verify data hasn't been tampered with in transit. A developer proposes encrypting the data with a strong symmetric cipher, reasoning that "encrypted data can't be tampered with."

The technician answer: encryption sounds like the strongest available control, so apply it — stronger crypto seems like it should solve any data-protection problem.

The manager (CISSP) answer: identify which property is actually required. The stated requirement is integrity (has the data been altered), not confidentiality (can the data be read) — and encryption alone doesn't guarantee integrity; an attacker who can't read encrypted data may still be able to corrupt or truncate it in transit without detection, depending on the cipher mode used. The correct tool for an integrity requirement is a cryptographic hash (or better, a keyed variant like an HMAC, which also proves authenticity) — reaching for "the strongest-sounding crypto primitive" without first identifying which of confidentiality, integrity, or authenticity is actually needed is the same category of mistake as Lesson 1's technician reaching for a fix without asking what property was actually violated.