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, cipher modes, code signing, key storage, and PKI lifecycle—without turning into a math textbook.

Pick the tool by security property

Every cryptography question on SY0-701 announces its answer in the first sentence if you listen for the goal. Confidentiality, integrity, authentication, non-repudiation—each pulls toward a different tool family, and mixing them up is how a distractor becomes your answer.

When you need to keep content secret, encryption is the answer—symmetric for bulk data, asymmetric for key exchange. When you need to detect tampering, you reach for a hash or a digital signature; encryption alone does not prove ciphertext arrived intact. When you need to verify passwords without storing them, a salted slow-KDF is correct—not plain AES, because then key management becomes the single point of failure. When you need to prove sender identity and integrity together, only a digital signature with an asymmetric pair delivers non-repudiation; a symmetric MAC cannot tell you which party holding the shared key wrote the message.

Tokenization replaces sensitive data with a surrogate mapped in a secure vault—useful in PCI designs where downstream systems need a reference but not the raw PAN. Data masking shows redacted values in lower environments. Neither is encryption, and the exam tests whether you can distinguish them from it.

Symmetric vs asymmetric—and why real protocols hybridize

Symmetric algorithms use one shared secret to encrypt and decrypt. AES is the exam reference—fast enough to encrypt a multi-gigabyte backup in seconds, right for bulk data. The hard problem is distribution: how do two strangers share a secret without an attacker reading the channel?

Asymmetric algorithms—RSA and the ECC family—solve that by splitting the key into a public half and a private half. You encrypt with the recipient's public key; only their private key can decrypt. You sign with your private key; anyone with your public key can verify. The math is slow, so real protocols hybridize: asymmetric operations handle identity proof and key agreement at session setup, then a symmetric key carries bulk traffic.

TLS is the canonical example. During the handshake, the server presents its certificate, the client validates the chain back to a trusted CA, and both sides agree on keying material through asymmetric math. Once a session key exists, every application byte travels under AES-GCM. The asymmetric phase is expensive enough to crawl if used on every response; the symmetric phase is fast enough that streaming video works without notice.

Forward secrecy enters the picture when the exam mentions ephemeral Diffie-Hellman (ECDHE). If the server's long-term private key leaks later, an attacker who recorded old sessions cannot decrypt them—because the ephemeral key was discarded after the handshake. That is the property modern TLS configurations protect.

The exam trap: "Which encrypts faster for a 10 GB backup stream?" lands on symmetric. "Which proves the server's identity in HTTPS?" lands on asymmetric certificate trust, then symmetric bulk.

Deprecated and weak algorithms—know what to retire

SY0-701 tests whether you can recognize algorithms that have been broken or fall beneath modern security margins. This is not historical trivia; regulators name this list in audit questionnaires, and exam stems often present a "legacy compatibility" excuse as the distractor.

When a stem describes a legacy application that only supports 3DES or SSLv3, "enable it for compatibility" is the distractor. The strong answer involves network isolation and a documented compensating control while remediation proceeds—never "backward compatibility" as a permanent answer.

Cipher modes: why ECB fails and GCM wins

Block ciphers operate in modes that determine how they handle plaintext longer than a single block. You do not need to implement them, but the exam's favorite contrast is worth understanding in plain language.

ECB (Electronic Code Book) encrypts each block independently using the same key. The consequence is that identical plaintext blocks produce identical ciphertext blocks, so patterns in the original data survive intact into the encrypted output. The classic illustration is encrypting a bitmap image in ECB mode and watching the shape of the original image remain recognizable through the ciphertext. ECB is wrong for almost any real use, and SY0-701 knows this.

GCM (Galois/Counter Mode) combines counter-mode encryption with a Galois message authentication code, providing confidentiality, integrity, and authentication in a single pass. It is the cipher mode behind TLS 1.3's mandatory cipher suites. When a stem asks which mode to use for an API that needs both privacy and tamper detection, GCM-class authenticated encryption is the strong answer.

Code signing and S/MIME—asymmetric trust applied

Code signing is asymmetric cryptography applied to software distribution. A developer signs a binary with their private key; the operating system or app store verifies the signature against the developer's certificate before allowing execution. If the signature is missing or the certificate is revoked, modern platforms warn or refuse to run. The security property at stake is integrity and authenticity, not confidentiality—nobody encrypts a public installer. The goal is proving the binary came from the stated publisher and was not modified after signing.

Supply-chain attacks often target this step precisely because a valid signature is so powerful. Compromise the signing key or the certificate, and you can distribute malware under a trusted name. This is why code-signing private keys belong in HSMs, not on developer laptops with shared filesystem access. The exam uses code signing to test the integrity vs confidentiality distinction: signing proves provenance; encrypting hides content. They are different tools for different properties.

S/MIME brings the same asymmetric machinery to email. A sender signs their outbound message with their private key; recipients verify with the sender's published certificate. That signature proves the message body arrived intact and that only the holder of that private key could have created it—supporting non-repudiation in a way TLS transport headers never can, because TLS secures the channel while S/MIME secures the object. S/MIME can also encrypt email: the sender encrypts with each recipient's public key so only those recipients can decrypt. The tradeoff is certificate management complexity—every participant needs a valid cert, and those certs must be distributed and mutually trusted. SY0-701 uses S/MIME to test the non-repudiation versus confidentiality distinction, not implementation details.

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

The most important property to identify first is whether the key can leave the hardware. From that constraint, the right tool follows.

A TPM (Trusted Platform Module) is a chip soldered to a motherboard. Keys generated there are bound to that platform—by design, they should not export to another machine. The exam scenario is full-disk encryption: BitLocker seals the volume key to the TPM and optionally a PIN, so pulling the drive and attaching it elsewhere yields encrypted noise. TPM is platform-rooted trust, not an enterprise signing appliance.

An HSM (Hardware Security Module) is an appliance or PCIe card for high-assurance cryptographic operations at scale. Certificate authorities use HSMs to sign certificates so the root CA private key never touches general-purpose software; code-signing pipelines should route through them too. Keys are non-exportable; operations are logged and role-separated. HSM is the answer when the stem says "private key must never leave hardware" at enterprise or CA scale.

KMS (Key Management Service) is the cloud-era vocabulary for centralized key lifecycle management—create, rotate, revoke, and audit keys that protect data at rest. Cloud envelope encryption uses a KMS-managed Key Encryption Key (KEK) to wrap Data Encryption Keys (DEKs); rotating the KEK re-encrypts DEKs without touching raw data. The exam tests whether customer-managed KMS keys differ from provider-managed: control of the KEK means control over whether decryption can happen at all.

A secure enclave provides isolated CPU execution—Intel SGX-style at exam depth—so code inside the enclave cannot be inspected even by the OS. The scenario is protecting keys while in use, not just at rest.

The trap that appears every exam cycle: TPM ≠ HSM. TPM is platform-attached and answers "was this laptop's boot state clean and intact?" HSM is an enterprise appliance and answers "who can authorize a CA signing operation and how is that logged?"

PKI: chain, revocation, and lifecycle

Public Key Infrastructure binds identities to public keys through certificates signed by Certificate Authorities. The chain of trust runs from a root CA—a self-signed trust anchor that ships in OS and browser trust stores—through one or more intermediate CAs to a leaf certificate that identifies a server, user, or device. Failure at any link in that chain—expired intermediate, revoked leaf, mismatched hostname—breaks validation.

Revocation is where the exam hides meaningful complexity. A CRL (Certificate Revocation List) is a file the CA publishes with revoked serial numbers; clients download and check it, but the list can be hours stale. OCSP lets a client query the CA in real time for a specific certificate's status—fresher, but adds a network dependency. OCSP stapling has the server attach a recent signed OCSP response to the TLS handshake, so the client gets freshness without contacting the CA directly. The exam distinguishes these by the tradeoff each presents.

An expired certificate and a revoked certificate both fail validation, but the remediation differs: renew an expired cert; reissue and remove trust for a revoked one. A CSR is what a subject submits to request certification of its public key. Wildcards (*.example.com) cover subdomains but increase blast radius if the private key leaks; SAN certificates list explicit names and represent current practice.

Key escrow stores a copy of private keys with a trusted custodian for recovery—useful when an employee departs without transferring keys, but it introduces the custodian as a potential attack or coercion surface. SY0-701 frames it as a tradeoff, not a recommendation.

Encryption scope: at rest, in transit, in use

TLS on the wire does not protect a file sitting on a server after it is decrypted and saved. Full-disk encryption protecting a powered-off laptop does not help while the OS is running and decryption is live. Exam stems frequently construct scenarios around mismatched scope—the control implemented does not cover the threat in the incident. A stolen laptop with FDE and a strong pre-boot PIN is protected at rest if it was powered off when taken; TLS to cloud applications is irrelevant to offline disk forensics if FDE was never configured. Match the scope of the control to the scope of the threat, and most of these scenarios resolve cleanly.

Exam traps summary

Closing frame

Security+ crypto success is decision quality, not memorizing block sizes or algorithm retirement years. 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 a dispute. When engineering wants to "just encrypt passwords," you explain why salted KDFs exist and what key management would cost. When a stem mentions ECB mode or RC4, you name the property that fails and what replaces it. That reasoning pattern—property first, tool second, scope always—is exactly what SY0-701 rewards.

Companion reading: the Security Controls, CIA, and AAA post for the control classification framework that underpins every crypto decision, and the Data Protection and Resilience post for encryption scope applied to backup and continuity scenarios.