Cryptography and PKI for Security+: What You Must Actually Reason About

During a tabletop exercise, legal asks whether emailed contract PDFs were tampered with. Engineering says "they were TLS-downloaded, so we're fine." You pause: TLS protects in transit, not after save. Legal needs integrity at rest and non-repudiation on signatures—not "HTTPS was green." SY0-701 cryptography questions feel like trivia until you frame them as property + lifecycle + key custody decisions. This post covers what to reason about: encryption vs hashing, symmetric vs asymmetric, key storage, PKI lifecycle, and exam traps—without turning into a math textbook.

Goals first: pick the tool by security property

Tokenization replaces sensitive data with a surrogate token mapped in a secure vault—useful in PCI-style designs. Data masking shows redacted or fictional values in lower environments. Neither is interchangeable with "encrypt everything the same way."

Worked example: password database leak

A breach exposes user_table with columns username, password_hash. Hashes are unsalted SHA-256.

• Property lost: confidentiality of credentials (offline cracking).
• Fix direction: unique salt per password + slow KDF (bcrypt, scrypt, Argon2 class)—not "encrypt the hash column with AES" (key management becomes the new single point of failure).
• Exam angle: "Encrypt passwords" is almost always wrong wording; hash with salt is the pattern.

Symmetric vs asymmetric encryption

Symmetric algorithms (AES is the common exam reference) use one shared secret key for encrypt and decrypt. Fast for bulk data. Hard part: how do two parties share the key without an attacker copying it?

Asymmetric algorithms (RSA, ECC families) use key pairs: public key encrypts or verifies; private key decrypts or signs. Solves distribution for key exchange and identity. Slower—so real protocols hybridize.

Typical TLS handshake pattern (conceptual):

1. Asymmetric step establishes identity and agrees session material.
2. Symmetric session keys encrypt bulk traffic for performance.

Key exchange protocols (Diffie–Hellman, ECDHE in modern TLS) let parties derive shared secrets over an untrusted channel without transmitting the secret itself—forward secrecy enters advanced stems when ephemeral keys limit past session decryption if long-term keys leak.

Exam trap: "Which encrypts faster for a 10 GB backup stream?" → symmetric. "Which proves server identity in HTTPS?" → certificate-backed asymmetric trust, then symmetric bulk.

Hashing, salting, and stretching

Hashing maps input to fixed-length digest; one-way under exam assumptions. Used for integrity checks and password verifiers.

Salting adds unique random data per record before hash—defeats rainbow tables because crackers must attack each salt separately.

Key stretching / KDF repeats hash or memory-hard work—slows offline guessing.

Digital signatures combine asymmetric keys with hash of document: private key signs hash; anyone with public key verifies integrity and signer binding—supports non-repudiation when keys are well governed.

Obfuscation vs encryption

Obfuscation hides meaning without strong cryptographic guarantees (encoding, simple XOR toys). Encryption assumes rigorous key control. Exams may mention steganography hiding data inside images/audio—secrecy of existence, not just content.

Do not pick obfuscation when the stem demands regulatory-grade confidentiality.

Where keys live: TPM, HSM, KMS, secure enclave

Key custody questions dominate SY0-701 crypto scenarios.

Why it matters: "Private key must never leave hardware" → HSM or TPM-backed workflow, not a .pem on a share. "Cloud service encrypts S3 objects with customer-managed keys" → KMS vocabulary.

Exam trap: TPM ≠ HSM. TPM is platform-attached trust anchor; HSM is often appliance/module for enterprise signing with stricter ops controls.

PKI building blocks

Public Key Infrastructure binds identities to public keys via certificates signed by Certificate Authorities (CAs).

Core objects:

• Public key — distributed freely
• Private key — strictly protected; loss = impersonation
• Certificate — CA statement: "this public key belongs to this subject"
• CSR (Certificate Signing Request) — entity requests certification of its public key
• Root of trust — anchor CA your system trusts

Chain validation (simplified):

Root CA (self-signed trust anchor)
  → Intermediate CA
    → Leaf certificate (server or user)

Failure at any link → browser/app warnings or silent trust breaks in APIs.

Revocation: CRL vs OCSP

Exam trap: expired certificate vs revoked certificate—both fail validation, but fix differs (renew vs reissue + remove trust). Wrong hostname in cert (CN/SAN mismatch) fails identity check even if chain is valid.

Wildcard and SAN certificates

Wildcard (*.example.com) simplifies admin for subdomains but increases blast radius if private key leaks—any matching host impersonation. Subject Alternative Name (SAN) lists explicit names; modern practice favors SAN-heavy certs over legacy CN-only thinking.

Self-signed vs public CA

Self-signed certs require explicit trust store installation—fine for labs/internal PKI, risky if users are trained to click through warnings. Public CAs anchor trust for the open internet.

Key escrow

Key escrow stores keys with a third party for recovery (legal/compliance/business continuity). Tension: aids decryption after employee loss; increases insider/government access risk. Exams present as tradeoff, not "always good."

Encryption scope: at rest, in transit, in use

Full-disk encryption (FDE) vs file/volume vs record-level field encryption—stem chooses based on granularity and key management appetite. Database TDE protects storage media; app-layer field encryption adds finer control with more dev cost.

Worked example: stolen laptop

Controls:

• FDE with TPM + PIN → protects at rest if powered off
• Screen lock + idle timeout → reduces in use exposure
• Remote wipe → corrective containment

TLS to cloud apps does not help offline disk forensics if FDE absent or weak password.

Blockchain / distributed ledger (exam depth)

SY0-701 expects concept-level knowledge: chained blocks, hashes linking integrity, distributed copies reducing single-point tamper—not deploying production smart contracts. Exam angles tie to integrity and audit trails where many parties must agree on history without a single editor.

Common cryptography exam traps

1. "Encrypt password database" → should be salted hash.
2. Hash for confidentiality → hashes do not hide data from anyone who can guess inputs.
3. Symmetric for web server identity → need certificates (asymmetric trust).
4. Revocation ignored → client must check CRL/OCSP; misconfig trusts revoked certs.
5. Downgrade attacks → outdated protocols (SSLv3, weak ciphers) enabled "for compatibility."
6. Same key encrypt and sign (bad practice) → key reuse across contexts breaks isolation—exams hint at separation of duties for keys.

Comparison: when auditors ask different questions

How to practice

1. Property drill: for ten assets (email, VPN creds, contract PDF, API token), assign confidentiality/integrity/availability/non-repudiation needs and pick controls.
2. TLS storyboard: draw client-server handshake; label asymmetric vs symmetric phases.
3. Break-the-chain lab: import a cert with missing intermediate; observe failure; fix trust store.
4. Revocation check: use openssl ocsp or browser dev tools to see OCSP status on a live site (read-only recon).
5. Flashcard ban: instead of algorithm acronyms alone, write scenario → choice → because.

Security+ crypto success is decision quality, not memorizing block sizes. When legal asks about tampered PDFs, you answer with signatures and hashes, clarify TLS scope, and point to HSM-backed signing if non-repudiation must survive dispute—exactly the reasoning SY0-701 rewards.