3 Cryptographic Solutions · Security+

Exam objective 1.3: Explain the importance of using appropriate cryptographic solutions. This objective covers the cryptographic building blocks that protect data and identities across every other domain of the exam. It includes public key infrastructure (PKI) with public keys, private keys, and key escrow; certificates, certificate authorities, CRLs, OCSP, self-signed and third-party certificates, the root of trust, CSR generation, and wildcard certificates; encryption protocols, symmetric and asymmetric encryption, levels of encryption from full disk down to individual records, transport encryption, key exchange, algorithms, and key length; and digital signatures, salting, hashing algorithms, cryptographic tools such as TPMs and HSMs, and obfuscation techniques such as steganography and tokenization. It closes with an awareness-level look at post-quantum cryptography.

This is an "explain" objective. You will not be asked to do math, but you must understand what each cryptographic tool does, which security goal it serves, and why one solution is more appropriate than another in a given situation. Expect questions such as: which key encrypts a message for a recipient, which mechanism checks whether a certificate has been revoked, which algorithm is deprecated, which hardware component stores a disk encryption key, or which technique replaces a credit card number with a meaningless value. The word "appropriate" in the objective is the key: most wrong answers on cryptography questions are real technologies applied to the wrong problem.

Cryptography Fundamentals

Cryptography is the practice of protecting information by transforming it so that only authorized parties can read it or verify it. Chapter 1 introduced the goals cryptography supports, and it helps to map each tool to a goal from the start:

Goal Question it answers Cryptographic tool

Confidentiality Can anyone else read this? Encryption (symmetric or asymmetric)

Integrity Has this been changed? Hashing, HMAC, digital signatures

Authentication Who or what is this really? Certificates, digital signatures, challenge-response Non-repudiation Can the sender deny it? Digital signatures (private key)

A few basic terms appear throughout the chapter:

Plaintext (or cleartext) is readable data before encryption. Ciphertext is the scrambled output.
A cipher (or algorithm) is the mathematical procedure for encryption and decryption.
A key is a secret value that controls the cipher's output. The same algorithm with different keys produces completely different ciphertext.
Key length (key size) is the number of bits in the key. Longer keys mean more possible keys and more work for an attacker trying them all.
Work factor is the time and effort required to break a cryptographic protection.

Modern cryptography follows Kerckhoffs's principle: a system should remain secure even if everything about it except the key is public. AES, RSA, and SHA-256 are published, scrutinized standards. Their security comes from the secrecy and length of keys, not from hiding how they work. "Security through obscurity"—relying on a secret algorithm—is weak, which is why homegrown or proprietary ciphers are a red flag on the exam.

Symmetric Encryption

Symmetric encryption uses the same key to encrypt and decrypt. The sender and recipient must both possess the shared secret key.

Symmetric algorithms are fast and efficient, which makes them the workhorse for encrypting large amounts of data: disks, files, databases, and the bulk of network traffic. Their weakness is key distribution. How do two parties who have never met agree on a secret key without an eavesdropper learning it? And in a group of n people who all need to communicate privately in pairs, the number of keys grows quickly: n(n-1)/2. Fifty people need 1,225 unique keys. Asymmetric cryptography and key exchange, covered shortly, solve these problems.

Block and Stream Ciphers

A block cipher encrypts data in fixed-size blocks (AES uses 128-bit blocks). Data that does not fill a block is padded.
A stream cipher encrypts data one bit or byte at a time by combining it with a keystream. Stream ciphers suit real-time data such as voice and video. ChaCha20 is the modern example; RC4 is an old, broken one.

Block ciphers use a mode of operation to handle data longer than one block. ECB encrypts each block independently and is insecure because identical plaintext blocks produce identical ciphertext. CBC chains blocks together, CTR turns a block cipher into a stream cipher, and GCM adds built-in authentication (authenticated encryption, or AEAD) and is preferred in TLS 1.3. Most modes use an initialization vector (IV) or nonce—a unique value ensuring that the same plaintext encrypted twice produces different ciphertext.

Common Symmetric Algorithms
Algorithm Key length Block size Status
DES 56 bits 64 bits Broken; brute-forceable in hours

3DES (Triple DES)

112 or 168 bits (effective
~112)
64 bits Deprecated and disallowed by NIST for new encryption
Algorithm Key length Block size Status

AES (Rijndael) 128, 192, or 256 bits 128 bits Current standard; used everywhere ChaCha20 256 bits Stream cipher Modern; fast in software and on mobile devices RC4 40-2048 bits Stream cipher Broken; prohibited in TLS

AES (Advanced Encryption Standard) is the algorithm to know. Selected by NIST in 2001, it supports 128-, 192-, and 256-bit keys (10, 12, and 14 rounds respectively). AES-256 is often required for highly sensitive data and is considered resistant even to anticipated quantum attacks. Modern processors include AES-NI hardware instructions, making AES very fast.

Exam tip

If a question asks for the best algorithm to encrypt large amounts of data quickly—a hard drive, a backup set, a database—the answer is symmetric encryption, usually AES. If an answer choice lists DES, 3DES, or RC4, it is almost certainly a distractor representing a weak or deprecated algorithm.

Asymmetric Encryption

Asymmetric encryption, also called public key cryptography, uses a mathematically related key pair:

The public key can be shared freely with anyone. It is published in certificates, directories, and websites.
The private key must be kept secret by its owner and never shared.

What one key does, only the other key can undo. This gives two distinct uses:

Encryption for confidentiality: encrypt with the recipient's public key. Only the recipient's private key can decrypt. Anyone can send a confidential message; only the intended recipient can read it.
Signing for authentication, integrity, and non-repudiation: sign with the sender's private key. Anyone with the sender's public key can verify the signature, proving the sender created it. Asymmetric cryptography solves the key distribution problem—you can publish your public key without risk—and each person needs only one key pair regardless of how many correspondents they have. Its drawback is speed: asymmetric operations are hundreds to thousands of times slower than symmetric ones, so they are not used to encrypt bulk data.

Memory aid

"Encrypt to them, sign as me." To send a secret, use their public key. To prove it is from you, use your private key. Your private key never leaves your possession, and you never use someone else's private key for anything.

Hybrid Encryption

Real systems combine both types. In hybrid encryption, asymmetric cryptography is used to securely exchange or protect a randomly generated symmetric session key, and then the fast symmetric algorithm encrypts the actual data. TLS, S/MIME, PGP, and SSH all work this way. When you visit an HTTPS website, asymmetric cryptography authenticates the server and establishes a shared secret, and AES or ChaCha20 then encrypts the page content.

Figure 3.1: Hybrid encryption uses asymmetric cryptography to protect a session key and symmetric cryptography to encrypt the data

Common Asymmetric Algorithms

RSA (Rivest-Shamir-Adleman) relies on the difficulty of factoring the product of two very large prime numbers. It supports encryption, digital signatures, and (historically) key transport. Common key sizes are 2048 bits (current minimum) and 3072 or 4096 bits for longer-term protection.
ECC (Elliptic Curve Cryptography) relies on the difficulty of the elliptic curve discrete logarithm problem. ECC achieves equivalent security with much smaller keys—a 256-bit ECC key is roughly comparable to a 3072-bit RSA key—which means less computation, less power, and less bandwidth. That makes ECC ideal for mobile devices, IoT, and smart cards. Common curves include P-256, P-384, and Curve25519.
DSA / ECDSA (Digital Signature Algorithm / Elliptic Curve DSA) are used for digital signatures only, not encryption. EdDSA (such as Ed25519) is a modern, fast signature scheme.
Diffie-Hellman (DH) and its elliptic curve version ECDH are key agreement algorithms, used to establish a shared secret rather than to encrypt data or sign. They are covered in the key exchange section.

Algorithm Based on Used for Typical key size

RSA Integer factorization Encryption, signatures, key transport

2048-4096 bits

ECC (ECDSA, ECDH, EdDSA)

Elliptic curve discrete logarithm Signatures, key agreement 256-384 bits DSA Discrete logarithm Signatures only 2048-3072 bits

Diffie-Hellman Discrete logarithm Key agreement only 2048+ bits

Common trap

Diffie-Hellman does not encrypt data and does not authenticate anyone by itself. It lets two parties derive a shared secret over an insecure channel. Unauthenticated DH is vulnerable to on-path (man-in-the-middle) attacks, which is why real protocols combine DH with certificates or signatures to prove identities.

Key Exchange

Key exchange is the process by which two parties establish a shared symmetric key over an untrusted network. There are two broad approaches:

Key transport: one party generates a session key and sends it encrypted with the other party's public key. Older TLS versions used RSA key transport: the browser encrypted a pre-master secret with the server's RSA public key.
Key agreement: both parties contribute values and each independently computes the same shared secret, which never crosses the network. Diffie-Hellman is the classic key agreement protocol.

In Diffie-Hellman, each party generates a private value, computes a public value from it, and sends the public value to the other. Each then combines its own private value with the other's public value and arrives at the same result. An eavesdropper who sees both public values cannot feasibly compute the shared secret.

Ephemeral Keys and Perfect Forward Secrecy

ECDHE (Elliptic Curve Diffie-Hellman Ephemeral) and DHE (Diffie-Hellman Ephemeral) generate fresh, temporary key pairs for every session and discard them afterward. This provides perfect forward secrecy (PFS): if an attacker later steals the server's long-term private key, they still cannot decrypt previously recorded sessions, because each session's keys were ephemeral and are gone. Compare that with RSA key transport. If an attacker records years of encrypted traffic and later obtains the server's RSA private key, they can decrypt every recorded session's pre-master secret and therefore all the traffic. This is why TLS 1.3 removed RSA key transport entirely and requires ephemeral (EC)DHE for every connection.

Method Shared secret crosses network? Forward secrecy?

Status

RSA key transport Yes, encrypted with server's public key

No Removed in TLS 1.3

Static DH/ECDH No No Uncommon

DHE / ECDHE No Yes Required in TLS 1.3; ECDHE preferred

Exam tip

When a question asks how to ensure that compromise of a server's private key does not expose past sessions, the answer is perfect forward secrecy using ephemeral key exchange such as ECDHE. When a question asks which algorithm establishes a shared secret over an insecure channel, the answer is Diffie-Hellman (or ECDH/ECDHE).

Key Length and Algorithm Strength

Key length determines how many possible keys exist. Each additional bit doubles the keyspace: a 128-bit key has 2^128 possibilities, an astronomically large number that cannot be brute-forced with classical computers. A 56-bit DES key, by contrast, can be exhausted with modest hardware.

Symmetric and asymmetric key lengths cannot be compared directly, because the attacks against them differ. A brute-force attack against AES must try keys; an attack against RSA attacks the mathematical structure (factoring), which is far more efficient than guessing. NIST publishes comparable-strength guidance:

Security strength Symmetric RSA / DH ECC Hash (collision resistance)
112 bits 3DES (legacy) 2048 224 SHA-224
128 bits AES-128 3072 256 SHA-256
192 bits AES-192 7680 384 SHA-384
256 bits AES-256 15360 512+ SHA-512

Longer keys are stronger but slower, which is one reason ECC's small keys have largely displaced RSA in new designs. Key length is also not everything: a long key in a broken algorithm, a broken mode such as ECB, or a system with poor random number generation is still weak. Organizations define a cryptoperiod (how long a key may be used) and rotate keys accordingly.

Note

The exam may use the phrase cryptographic agility (crypto agility): designing systems so that algorithms and key lengths can be replaced without redesigning everything. Agility matters because algorithms weaken over time—MD5, SHA-1, DES, and RC4 were all once trusted—and because post-quantum algorithms are now being adopted.

Encryption Protocols and Transport Encryption

The objective lists protocols and transport/communication encryption. Data in transit crosses networks you do not control, so it must be encrypted to prevent eavesdropping and tampering. Each major protocol uses the hybrid approach: asymmetric cryptography for authentication and key exchange, symmetric cryptography for bulk data, and hashing (HMAC or AEAD) for integrity.

Tls

Transport Layer Security (TLS) secures HTTPS, email transport, LDAPS, many VPNs, and countless APIs. TLS replaced the older SSL protocol; SSL 2.0, SSL 3.0, TLS 1.0, and TLS 1.1 are all deprecated and should be disabled. TLS 1.2 remains acceptable with strong cipher suites, and TLS 1.3 (2018) is preferred. TLS 1.3 simplified the handshake to one round trip, removed weak options (RSA key transport, CBC-mode ciphers, SHA-1, RC4), requires forward secrecy, and encrypts more of the handshake.

In a TLS 1.3 handshake, the client and server exchange ECDHE key shares, the server presents its certificate and signs the handshake to prove it holds the private key, both sides derive symmetric session keys, and application data is then encrypted with an AEAD cipher. A TLS 1.3 cipher suite name such as TLS_AES_256_GCM_SHA384 names the symmetric cipher and mode (AES-256-GCM) and the hash used for key derivation (SHA-384); TLS 1.2 names such as ECDHE-RSA-AES128-GCM-SHA256 also list the key exchange and authentication algorithms.

Common trap

Attackers may attempt a protocol downgrade attack, tricking client and server into negotiating an older, weaker protocol version or cipher suite. Disabling legacy protocols on servers (and clients) removes the option. Downgrade indicators are covered in Chapter 8.

IPsec

IPsec secures traffic at the network layer and is commonly used for site-to-site and remote access VPNs (Chapter 11). Key components:

IKE (Internet Key Exchange), on UDP port 500 (and UDP 4500 for NAT traversal), negotiates security associations and keys using Diffie-Hellman.
AH (Authentication Header), IP protocol 51, provides integrity and authentication but no encryption.
ESP (Encapsulating Security Payload), IP protocol 50, provides encryption plus integrity and authentication.
Transport mode protects only the payload (host-to-host). Tunnel mode encrypts the entire original packet and adds a new IP header (gateway-to-gateway VPNs).

Other Secure Protocols

Insecure protocol Secure replacement Port(s) Cryptography used

Telnet (23) SSH TCP 22 Asymmetric host keys, DH/ECDH, symmetric session

FTP (20/21) SFTP (over SSH) or FTPS (over TLS)

Tcp 22 / tcp 989-

990
SSH or TLS
HTTP (80) HTTPS TCP 443 TLS
LDAP (389) LDAPS TCP 636 TLS
SMTP (25) SMTPS or SMTP with STARTTLS TCP 465 / 587 TLS
POP3 (110) / IMAP (143) POP3S / IMAPS TCP 995 / 993 TLS
SNMPv1/v2c (161) SNMPv3 UDP 161 Authentication and encryption

WEP / WPA WPA3 (or WPA2 with AES-CCMP)n/a (wireless) AES, SAE key exchange For email messages themselves (end-to-end, not just the transport hop), S/MIME uses X.509 certificates from a PKI, while PGP/GPG uses a decentralized web of trust. Both sign and encrypt individual messages.

Real-world scenario

An auditor finds that a legacy line-of-business application authenticates users by binding to the directory over LDAP on port 389, sending credentials in cleartext across the data center network. The appropriate cryptographic solution is to move the application to LDAPS on port 636 (or LDAP with StartTLS) using a certificate trusted by the application. Simply encrypting the directory database at rest would not help, because the exposure is in transit.

Levels of Encryption

Encryption can be applied at different levels of granularity. The objective lists full disk, partition, volume, file, database, and record. Each protects against different threats, and choosing the right level is a common exam task.

Full-Disk Encryption (FDE)

Full-disk encryption encrypts the entire storage device, including the operating system, swap or page files, temporary files, and free space. Examples include Microsoft BitLocker, Apple FileVault, and Linux LUKS. Self-encrypting drives (SEDs) perform FDE in the drive's own hardware, often following the TCG Opal standard.

FDE protects data when a device is powered off and lost or stolen: a thief who removes the drive sees only ciphertext. Its key limitation is that once the system boots and the user authenticates, data is decrypted transparently for anyone using the running system—including malware. FDE does not protect data from an attacker who has compromised a logged-in session, and it does not protect files once they are copied elsewhere.

Partition and Volume Encryption

A partition is a defined section of a physical disk. Partition encryption encrypts one partition while leaving others unencrypted—for example, encrypting a data partition but not a recovery partition. A volume is a logical storage unit that the operating system mounts and assigns a drive letter or mount point; it may span part of one disk or several disks. Volume encryption protects a specific volume, such as a BitLocker-encrypted D: drive, a removable USB drive (BitLocker To Go), or an encrypted container file mounted as a virtual volume (such as VeraCrypt). Volume encryption is useful when only certain data stores need protection or when portable media must be secured.

File-Level Encryption

File encryption encrypts individual files or folders. Examples include Windows Encrypting File System (EFS), encrypted archive files (such as AES-encrypted ZIP or 7z), and PGP-encrypted files. File encryption can protect sensitive files from other users of the same system, including administrators in some configurations, and protection can travel with the file when it is copied or emailed (depending on the method). The trade-off is management: users or policies must decide which files to encrypt, and temporary copies may be left unencrypted.

Database Encryption

Database encryption protects data stored in a database. The most common approach is transparent data encryption (TDE), offered by SQL Server, Oracle, and others, which encrypts database files and backups at rest without changes to the application. Like FDE, TDE protects against theft of the underlying files or backup media but not against someone who can query the database through the application or with valid credentials.

Record-Level Encryption

Record-level encryption (and the closely related column-level or field-level encryption) encrypts specific records or specific fields within a database—for example, only the Social Security number column, or only the records belonging to a particular customer. Data stays encrypted even when the database is queried, and only users or applications with the right keys can decrypt those values. This provides granular protection against insiders such as database administrators who have access to the database but have no need to see sensitive values. The cost is complexity and performance: encrypted fields are harder to search, index, and sort.

Level Protects Example Does NOT protect against

Full disk Entire drive when powered off

BitLocker, FileVault, LUKS,

Sed

Malware or users on the running, unlocked system

Partition One partition of a disk Encrypted data partition Data on other partitions Volume A logical volume or removable drive

BitLocker To Go, VeraCrypt container

Data copied off the volume

File Individual files or folders EFS, PGP-encrypted file Unencrypted temp copies, other files Database Database files and backups at rest

Transparent data encryption

Authorized queries that return plaintext

Record Specific rows or fields Encrypted SSN column Users or apps that hold the decryption key

Exam tip

Match the level to the threat. Lost laptops point to full-disk encryption. Stolen backup tapes of a database point to database (TDE) or backup encryption. A database administrator who should not see credit card numbers points to record-level or field-level encryption (or tokenization). A sensitive file emailed outside the company points to file-level encryption.

Public Key Infrastructure (PKI)

Asymmetric cryptography raises an obvious question: when you download someone's public key, how do you know it really belongs to them and not to an attacker impersonating them? Public key infrastructure (PKI) answers that question. PKI is the combination of hardware, software, people, policies, and procedures used to create, manage, distribute, use, store, and revoke digital certificates, which bind public keys to identities.

Public and Private Keys in PKI

In a PKI, every subject—a person, a server, a device, or a code-signing entity—has a key pair. The public key is embedded in a certificate and distributed openly. The private key stays with the subject, ideally generated and stored in protected hardware (a smart card, TPM, or HSM) so that it can never be exported. The security of the entire system depends on private keys remaining private. If a private key is compromised, the corresponding certificate must be revoked immediately, because anyone holding the key can impersonate the subject or decrypt data meant for it.

Key Escrow and Key Recovery

Key escrow is the practice of storing a copy of cryptographic keys with a trusted third party or a designated internal function so that they can be recovered if needed. Reasons for escrow include:

Recovering encrypted business data when an employee loses a key, leaves the organization, or dies.
Meeting legal or regulatory requirements for access to encrypted data.
Supporting investigations under proper legal authority.

A related mechanism is key recovery, where a designated key recovery agent can restore a lost encryption key. For example, Active Directory can escrow BitLocker recovery keys, and Microsoft's EFS supports data recovery agents.

Escrow creates a high-value target: whoever holds escrowed keys can decrypt protected data. Escrow systems should therefore use strong access controls, separation of duties, and M-of-N control (also called split knowledge or quorum), in which several of a defined group of custodians—for example, any three of five—must cooperate to recover a key. As a rule, organizations escrow encryption keys (so data is recoverable) but do not escrow private keys used only for digital signatures, because a copy of a signing key held by someone else would undermine non-repudiation.

Common trap

Do not confuse key escrow with a certificate authority. A CA vouches for public keys by signing certificates; it does not normally hold anyone's private key. Key escrow is specifically about keeping recoverable copies of keys.

PKI Components

Beyond the certificate authority (CA), which issues, signs, and revokes certificates, a PKI may include a registration authority (RA) that verifies requesters' identities before issuance, a repository that publishes certificates, CRL and OCSP services that publish revocation status, and a key recovery function. A certificate policy (CP) and certification practice statement (CPS) document the rules the CA follows. Certificates move through a life cycle of request, issuance, use, renewal, and expiration or revocation. Expired certificates are a common cause of outages, which is why certificate inventory and automated renewal (for example, with the ACME protocol) are operational priorities and a change management concern (Chapter 2).

Digital Certificates

A digital certificate is an electronic document that binds a public key to an identity and is digitally signed by an issuer. Most certificates follow the X.509 standard and contain:

Version and serial number (unique per issuing CA, used in revocation lists).
Signature algorithm the CA used (for example, sha256WithRSAEncryption or ecdsa-with-SHA384).
Issuer: the CA that signed the certificate.
Validity period: Not Before and Not After dates.
Subject: the identity, such as CN=www.example.com, O=Example Corp.
Subject public key information.
Extensions, including Subject Alternative Name (SAN) listing additional names, Key Usage and Extended Key Usage (server authentication, client authentication, code signing, email protection), the CRL Distribution Point, and Authority Information Access (which includes the OCSP responder URL).

Certificate Authorities and the Chain of Trust

A certificate authority (CA) is a trusted entity that verifies identities and signs certificates. By signing a certificate, the CA vouches that the public key belongs to the named subject.

CAs are organized in a hierarchy:

The root CA sits at the top. Its certificate is self-signed, and it is the anchor of trust. Because compromise of a root would be catastrophic, root CAs are usually kept offline, often in an HSM in a secured facility, and are used only to sign intermediate CA certificates.
Intermediate CAs (also called subordinate or issuing CAs) are signed by the root and issue certificates to end entities. If an intermediate is compromised, it can be revoked without replacing the root.
End-entity (leaf) certificates are issued to servers, users, and devices.

When a browser receives a server certificate, it builds and validates the chain of trust: the leaf was signed by the intermediate, and the intermediate was signed by a root that the browser already trusts. At each step it checks the signature, validity dates, name match, key usage, and revocation status. Servers must send the intermediate certificates along with their own; a missing intermediate is a common misconfiguration that causes trust errors on some clients.

Figure 3.2: Each certificate in the chain of trust is signed by the one above it, and the client validates back to a trusted root Root of Trust

A root of trust is a source that is inherently trusted and from which other trust is derived. In PKI, the root of trust is the root CA certificate stored in the trust store of an operating system, browser, or application. Everything chains back to it. If an attacker can add a rogue root certificate to a trust store, they can issue certificates for any site and intercept TLS traffic without warnings—which is exactly what some malware and some corporate TLS inspection proxies do.

The term also applies to hardware. A hardware root of trust—such as a TPM, a secure enclave, or the immutable boot ROM in a processor—provides trusted keys and measurements that the rest of the system builds on, enabling secure boot and measured boot. The common idea is a small, highly protected foundation that must be trusted because it cannot be verified by anything beneath it.

Third-Party and Self-Signed Certificates

A third-party certificate is issued by a public, commercially recognized CA whose root certificates are preinstalled in browsers and operating systems. Third-party certificates are needed for public-facing services, because visitors' devices already trust those roots. Public CAs offer different validation levels:

Domain validation (DV): the CA confirms only that the requester controls the domain.
Organization validation (OV): the CA also verifies that the organization exists.
Extended validation (EV): the CA performs more rigorous identity checks on the organization. A self-signed certificate is signed by its own private key rather than by a CA. Every root CA certificate is self-signed, but the term usually refers to a server or device certificate that no CA vouches for. Self-76 signed certificates are free and quick, and they are acceptable for testing, lab use, or internal devices where trust is established another way. They are not appropriate for public services: browsers display warnings, and users trained to click through warnings become easy targets for on-path attacks. Between the two sits the private (internal) CA: an organization runs its own CA, such as Active Directory Certificate Services, and distributes its root certificate to company-managed devices. This is the usual choice for internal servers, VPN authentication, Wi-Fi 802.1X, and user smart cards.

Certificate source Trusted by Cost Appropriate for
Third-party (public)
CA

Virtually all browsers and devices Free to moderate

Public websites, public APIs, external email

Private internal CA Devices configured with the internal root

Internal operating cost

Intranet servers, VPN, 802.1X, internal users

Self-signed Only devices that explicitly trust that certificate

Free Testing, labs, isolated devices

CSR Generation

To obtain a certificate, a subject generates a key pair and then creates a certificate signing request (CSR). The CSR contains the public key and the requested identity information (subject name, SANs), and it is signed with the private key to prove possession. The private key is not included and never leaves the requester. The CA (or RA) validates the request and returns a signed certificate. # Generate a 2048-bit RSA private key and a CSR in one step

$ openssl req -new -newkey rsa:2048 -nodes \
-keyout portal.example.com.key -out portal.example.com.csr \
-subj "/C=US/O=Example Corp/CN=portal.example.com" \

-addext "subjectAltName=DNS:portal.example.com,DNS:www.portal.example.com"

Common trap

The -nodes option in the example writes the private key without a passphrase. That is common for servers that must start unattended, but it means file permissions (or, better, an HSM or key vault) are the only protection for the key. If anyone asks you to send them your private key "to complete the certificate request," something is wrong: a CA needs only the CSR.

Wildcard and SAN Certificates

A wildcard certificate uses an asterisk in the leftmost label of the name, such as *.example.com, to cover all hosts at that one level: www.example.com, mail.example.com, and shop.example.com. A wildcard does not cover the bare domain example.com (unless it is listed separately as a SAN) and does not cover deeper levels such as dev.shop.example.com.

Wildcards simplify management and reduce cost, but they concentrate risk: the same private key is installed on many servers, so compromise of any one server compromises the certificate for every subdomain. A SAN (multi-domain) certificate lists specific names explicitly, which can cover different domains (example.com, example.net) and limits exposure to the named hosts.

Certificate Revocation: CRLs and OCSP

Certificates sometimes must be invalidated before they expire: the private key is compromised, the employee leaves, the server is decommissioned, or the certificate was issued in error. Revocation is the process of declaring a certificate no longer trustworthy, and clients need a way to check. A certificate revocation list (CRL) is a list, signed and published periodically by the CA, of the serial numbers of revoked certificates that have not yet expired. Clients download the CRL from the CRL distribution point (CDP) URL listed in the certificate. CRLs are simple, but they have drawbacks: they can grow large, and because they are published on a schedule, a newly revoked certificate may not appear until the next update.

The Online Certificate Status Protocol (OCSP) lets a client ask an OCSP responder about one specific certificate and receive a signed response of good, revoked, or unknown. OCSP is faster and more current than downloading an entire CRL. Its drawbacks are that the responder must be available and that the CA learns which sites a user visits (a privacy concern).

OCSP stapling addresses both problems: the web server periodically obtains a signed, time-stamped OCSP response for its own certificate and "staples" it to the TLS handshake, so clients do not need to contact the CA themselves.

Mechanis
m
How it works Advantage Disadvantage

CRL Client downloads CA's full list of revoked serial numbers

Simple; works offline once cached

Large; only as current as the last publication

OCSP Client queries responder about one certificate

Real-time, small responses Responder availability; privacy

Ocsp

stapling

Server attaches a recent signed OCSP response to the handshake

Fast; no client query to CA;
better privacy
Requires server support

Memory aid

CRL is a list you download—like a printed "do not accept" list of stolen credit cards. OCSP is a phone call asking about one card. Stapling is the merchant showing you a fresh, signed approval slip so you do not have to call.

Hashing

A hash function takes input of any length and produces a fixed-length output called a hash, digest, or fingerprint. Hashing is a one-way function: it is not encryption, there is no key, and you cannot "decrypt" a hash to recover the input. Hashes serve integrity: if even one bit of the input changes, the output changes dramatically (the avalanche effect).

A secure cryptographic hash must be:

Deterministic: the same input always yields the same hash.
Preimage resistant: given a hash, it is infeasible to find an input that produces it.
Second-preimage resistant: given an input, it is infeasible to find a different input with the same hash.
Collision resistant: it is infeasible to find any two different inputs with the same hash. A collision occurs when two inputs produce the same hash. Because outputs are fixed length and inputs are unlimited, collisions must exist mathematically; a secure hash makes finding them computationally infeasible. When practical collisions are found, the algorithm is considered broken for security uses such as signatures.

Hashing Algorithms

Algorithm Output size

Status

MD5 128 bits Broken; practical collisions since 2004. Not for security; acceptable only for non-adversarial checksums

SHA-1 160 bits Deprecated; practical collision demonstrated in 2017. Not acceptable for signatures

SHA-2 family (SHA-224,

Sha-256, sha-384,

SHA-512)

224-512 bits

Current standard; SHA-256 is the most widely used

SHA-3 family (SHA3-

256, SHA3-512, and others)

224-512 bits

Current standard (FIPS 202, 2015); different internal design (Keccak sponge construction)

SHA-2 remains secure and is what you will encounter most often in certificates, TLS, code signing, and file verification. SHA-3 was not created because SHA-2 was broken; it was standardized as an alternative with a completely different internal structure, so that a future weakness in one family would not affect the other—another example of crypto agility.

When asked which hashing algorithm to use for integrity verification or signatures, choose SHA-256 (or another SHA-2 or SHA-3 variant). MD5 and SHA-1 appear on the exam as examples of weak or deprecated algorithms. If a scenario describes two different files with the same hash, the term is a collision.

Hmac

A plain hash shows that data has not changed, but anyone can compute a hash—an attacker who alters a file can simply publish a new hash. A hash-based message authentication code (HMAC) combines a hash function with a shared secret key, so only parties who know the key can create or verify the value. HMAC (for example, HMAC-SHA256) provides integrity and authentication of origin among key holders. As Chapter 1 noted, because both parties share the key, HMAC does not provide non-repudiation.

Salting and Key Stretching

Systems should never store passwords in plaintext. Instead, they store a hash of the password; at login, they hash what the user typed and compare. But plain password hashing has two weaknesses:

Identical passwords produce identical hashes. If many users choose Summer2026!, their stored hashes are identical, and cracking one cracks them all.
Precomputation attacks. Attackers build rainbow tables—huge precomputed tables mapping hashes back to likely passwords—and simply look up stolen hashes. Fast hashes like MD5 and even SHA-256 can be computed billions of times per second on GPUs, making brute-force and dictionary attacks fast.

Salting

A salt is a random value, unique to each password, that is combined with the password before hashing. The salt is stored alongside the hash (it is not secret). Salting means:

Two users with the same password have different stored hashes.
Precomputed rainbow tables are useless, because the attacker would need a separate table for every possible salt.
Attackers must crack each hash individually.

User Salt (random, stored) Stored hash = H(salt + password)
alice 9f2c41e7a0b3d5c8 7d1a...e04b
bob c06e8b2f4d917a35 e93f...12ac

# alice and bob both chose "Summer2026!" -- the stored hashes are still different A pepper is a related secret value added to all passwords and stored separately from the database (for example, in an HSM or application configuration), so that a stolen database alone is insufficient for offline cracking.

Key Stretching

Key stretching makes each password guess deliberately expensive by running the hashing process many thousands of times or by requiring large amounts of memory. A legitimate login that takes 100 milliseconds is unnoticeable to a user, but it makes an attacker's billions of guesses enormously slower. Key stretching also turns a relatively weak password into a stronger cryptographic key for encryption purposes. Common algorithms:

PBKDF2 (Password-Based Key Derivation Function 2) applies an HMAC hash many times with a salt; the iteration count is configurable. Used by WPA2-Personal, many password managers, and FIPS-compliant systems.
bcrypt is based on the Blowfish cipher and includes a salt and an adjustable cost factor. Widely used for web application password storage.
scrypt is memory-hard, requiring significant RAM per guess, which makes GPU and custom-hardware attacks more expensive.
Argon2 (Argon2id is the recommended variant) won the Password Hashing Competition in 2015 and is memory-hard and tunable; it is the modern first choice.

Real-world scenario

A web retailer's user database is stolen. The passwords were stored as unsalted MD5 hashes, and within hours the attackers have cracked most of them using precomputed tables and GPU rigs, then use them for credential stuffing on other sites. After the incident, developers migrate to Argon2id with a unique salt per user and force password resets. Had the attackers stolen that new database, each guess would cost significant memory and time, and identical passwords would no longer reveal one another.

Exam tip

If a question asks how to defeat rainbow tables, the answer is salting. If it asks how to make brute-force attacks against stolen password hashes slower, the answer is key stretching (PBKDF2, bcrypt, scrypt, Argon2). Many good answers involve both.

Digital Signatures

A digital signature proves that a message or file came from the holder of a particular private key and that it has not been altered since it was signed. Digital signatures provide integrity, authentication of origin, and non-repudiation. They do not provide confidentiality—a signed message can be read by anyone unless it is also encrypted.

Signing works like this:

1. The sender hashes the message (for example, with SHA-256).
2. The sender encrypts (signs) the hash with the sender's private key. The result is the signature, which is attached to the message.
3. The recipient hashes the received message using the same algorithm.
4. The recipient uses the sender's public key (from the sender's certificate) to verify the signature and recover or check the original hash.
5. If the two hashes match, the message is intact and was signed by the private key holder. If they differ, the message was altered or the signature is not genuine.

Hashing first is important: it is much faster to sign a short fixed-length digest than an entire large file, and it ties the signature to the exact content.

Figure 3.3: The sender signs a hash with a private key and the recipient verifies it with the matching public key

Digital signatures are used for code signing of executables, drivers, and updates (Chapter 14), document and contract signing, S/MIME and PGP email, the TLS handshake, DNSSEC records, and every certificate (each is signed by its issuing CA). Common signature algorithms include RSA signatures, DSA, ECDSA, and EdDSA, paired with a SHA-2 hash.

Common trap

A common exam trap reverses the keys. The sender signs with the sender's private key; the recipient verifies with the sender's public key. Encrypting with the recipient's public key provides confidentiality, not a signature. If you need both, sign with your private key and then encrypt with the recipient's public key.

Cryptographic Tools

Cryptography is only as strong as the protection of its keys. The objective's tools are the hardware and services that generate, store, and use keys securely.

Trusted Platform Module (TPM)

A Trusted Platform Module (TPM) is a dedicated security chip (or firmware-based equivalent) built into a computer's motherboard or processor. TPM 2.0 is required by Windows 11. A TPM:

Generates and stores keys that cannot be exported from the chip.
Contains an endorsement key burned in at manufacture, uniquely identifying the TPM.
Holds platform configuration registers (PCRs) that record measurements (hashes) of firmware, bootloader, and OS components during startup—measured boot.
Seals secrets, such as a BitLocker volume key, so that they are released only if the boot measurements match the expected values. If someone tampers with the bootloader or moves the drive to another computer, the TPM will not release the key.
Supports remote attestation, letting a device prove its boot integrity to a server, which supports Zero Trust device health checks (Chapter 11).

A TPM is a per-device hardware root of trust. It is not designed for high-volume cryptographic operations.

Hardware Security Module (HSM)

A hardware security module (HSM) is a dedicated, tamper-resistant hardware appliance (or plug-in card) that generates, stores, and uses cryptographic keys at high speed for many applications. HSMs are typically validated against FIPS 140-2 or FIPS 140-3 and include tamper detection that erases keys if the device is physically attacked. Keys stay inside the HSM; applications send data to be signed or decrypted and receive the result.

Common HSM uses include protecting a CA's private keys, payment card processing (PIN encryption), database encryption master keys, code-signing keys, and TLS keys for high-traffic sites. Cloud providers offer dedicated HSMs as a service (for example, AWS CloudHSM and Azure Dedicated HSM). Key Management System (KMS)

A key management system (KMS) centrally manages the life cycle of cryptographic keys across an organization or cloud environment: generation, distribution, storage, rotation, access control, auditing, and destruction. Cloud services such as AWS KMS, Azure Key Vault, and Google Cloud KMS let administrators create keys, set policies about which identities can use them, rotate them automatically, and log every use. Many KMS services are themselves backed by HSMs.

A common KMS pattern is envelope encryption: data is encrypted with a data encryption key (DEK), which is itself encrypted with a key encryption key (KEK) that never leaves the KMS. Customers can also choose provider-managed keys, customer-managed keys, or bring your own key (BYOK) arrangements in which they generate or retain the master key.

Secure Enclave

A secure enclave is an isolated, hardware-protected execution environment within a processor that keeps code and data protected even from the main operating system and from a compromised kernel. Examples include Apple's Secure Enclave (which protects Face ID/Touch ID data and device encryption keys), ARM TrustZone, Intel SGX, and AMD SEV for virtual machines. The general term is a trusted execution environment (TEE). Secure enclaves are central to protecting data in use (Chapter 12), and they protect biometric templates and passkey private keys on mobile devices.

Tool Form Scope Typical use

TPM Chip on a device's motherboard or in firmware

One device Disk encryption keys, measured boot, attestation

HSM Dedicated network appliance or card

Many applications, high throughput

CA keys, payment keys, code signing, database master keys

KMS Software service (often HSM-backed)Organization or cloud-wide

Central key life cycle, rotation, access policy, auditing

Secure enclave

Isolated area inside a processor One device or VM Biometrics, device keys, protecting data in use Look for scale in the question. Protecting the BitLocker key on a single laptop is a TPM. Protecting the root CA's private key or performing thousands of signing operations per second is an HSM. Centrally rotating and auditing keys used by dozens of cloud services is a KMS. Protecting a fingerprint template on a phone is a secure enclave.

Obfuscation

Obfuscation makes information difficult to understand or find without necessarily using encryption. Obfuscation is not a substitute for encryption when strong confidentiality is required, but it is useful in specific situations. The objective highlights steganography, tokenization, and data masking.

Steganography

Steganography hides the existence of a message by concealing it inside another, ordinary-looking file or medium—an image, audio file, video, or even network packet headers. A common technique alters the least significant bits of image pixels; the image looks unchanged to a human, but the hidden data can be extracted by someone who knows where to look. The hidden message may also be encrypted first. Steganography has legitimate uses, such as digital watermarking to trace leaked documents or prove ownership of media. Attackers use it to exfiltrate data past DLP inspection, to hide command-and-control instructions in images posted on public sites, and to conceal malware payloads. Detecting it (steganalysis) relies on statistical analysis of files and on noticing unusual file sizes or traffic patterns.

Tokenization

Tokenization replaces a sensitive value with a non-sensitive substitute, called a token, that has no mathematical relationship to the original. The mapping between token and real value is stored in a secured token vault. Systems that handle only tokens never see the real data, so they are removed from the scope of many compliance requirements.

Tokenization is widely used in payment processing. When a customer's card is stored for recurring billing, the merchant keeps a token such as tok_4f8a9c21 instead of the card number. Mobile payment systems (such as Apple Pay and Google Pay) use device-specific tokens instead of the actual card number. If the merchant's database is breached, the tokens are useless to attackers.

Tokenization differs from encryption: ciphertext can be decrypted by anyone who obtains the key, while a token cannot be reversed mathematically at all—only by looking it up in the vault.

Data Masking

Data masking hides part or all of a value when it is displayed or used, for example showing only the last four digits of a card number (XXXX-XXXX-XXXX-4417) to a customer service representative, or substituting realistic but fake values in a test database. Static masking permanently replaces data in a copy (such as a dataset given to developers), while dynamic masking obscures data on the fly based on who is viewing it. Masking is covered further in Chapter 12 with other data protection methods.

Code Obfuscation

Developers obfuscate code (meaningless variable names, misleading logic, encoded strings) to hinder reverse engineering, and attackers obfuscate malicious scripts—such as Base64-encoded PowerShell— to evade detection. Encoding such as Base64 is obfuscation, not encryption: it uses no key and is trivially reversed.

Technique What it does Reversible? Typical use

Encryption Transforms data with a key Yes, with the key Confidentiality of data at rest and in transit

Hashing Produces a fixed-length digest No Integrity, password storage
Tokenizati
on

Substitutes a random token, mapping kept in a vault

Only via vault lookup Payment cards, reducing compliance scope

Masking Hides some or all characters Static: no; dynamic: underlying data unchanged

Displaying partial data, test data
Steganogra
phy

Hides data inside other data Yes, if you know the method

Watermarking; covert exfiltration

Post-Quantum Cryptography

Quantum computers exploit quantum mechanics to perform certain calculations far faster than classical computers. Two quantum algorithms matter for security:

Shor's algorithm can efficiently factor large numbers and compute discrete logarithms. A sufficiently large, fault-tolerant quantum computer running Shor's algorithm would break RSA, Diffie-Hellman, ECC, DSA, and ECDSA—essentially all of today's widely deployed public key cryptography.
Grover's algorithm speeds up brute-force search, effectively halving the security strength of symmetric keys and hashes. AES-128 would offer roughly 64-bit security against a quantum attacker, while AES-256 would still offer about 128-bit security, which is considered adequate. Symmetric cryptography survives by using longer keys.

No quantum computer capable of breaking RSA-2048 is publicly known to exist today, but the threat is already relevant because of harvest now, decrypt later (store now, decrypt later): adversaries can record encrypted traffic today and decrypt it once quantum capability arrives. Data that must remain confidential for many years—government secrets, health records, intellectual property—is at risk now. Post-quantum cryptography (PQC) refers to classical algorithms, running on ordinary computers, that are believed to resist attack by quantum computers. In August 2024, NIST published the first PQC standards:

FIPS 203, ML-KEM (Module-Lattice-Based Key-Encapsulation Mechanism, derived from CRYSTALS-Kyber) for key establishment.
FIPS 204, ML-DSA (derived from CRYSTALS-Dilithium) for digital signatures.
FIPS 205, SLH-DSA (derived from SPHINCS+), a hash-based digital signature scheme.

NIST has since selected additional algorithms as alternates and backups (such as FALCON-based FN-DSA for signatures and HQC for key encapsulation). Many TLS implementations and browsers already support hybrid key exchange that combines classical ECDHE (X25519) with ML-KEM, so a connection stays secure as long as either algorithm holds.

What organizations should do now:

Inventory where and how cryptography is used (a cryptographic bill of materials).
Prioritize long-lived sensitive data and systems with long lifespans.
Build crypto agility so algorithms can be swapped without redesign.
Use AES-256 and SHA-384 or larger where long-term protection is needed.
Plan migration to NIST PQC standards following vendor and government timelines.

Note

Do not confuse post-quantum cryptography with quantum cryptography (such as quantum key distribution), which uses quantum physics itself to exchange keys over specialized hardware. For SY0- 801, the key awareness points are: quantum computing threatens today's asymmetric algorithms; symmetric algorithms survive with longer keys; harvest-now-decrypt-later makes the threat current; and NIST's lattice-based ML-KEM and ML-DSA are the new standards.

Choosing Appropriate Cryptographic Solutions

Bringing it together, here is how to match common requirements to solutions:

Requirement Appropriate solution
Encrypt a large amount of data quickly Symmetric encryption (AES-256)
Requirement Appropriate solution

Send a confidential message to someone you have never met

Recipient's public key (hybrid encryption with a session key)

Prove who sent a message and prevent denial Digital signature with sender's private key Verify a downloaded file has not been altered SHA-256 hash compared to a trusted published value, or a code signature

Store user passwords Salted, stretched hash (Argon2, bcrypt, PBKDF2)

Protect past sessions if a server key is stolen Ephemeral key exchange (ECDHE) for perfect forward secrecy

Protect a stolen laptop's data Full-disk encryption with TPM

Hide card numbers from systems that do not need them Tokenization

Check whether a certificate was revoked, in real time OCSP (ideally with stapling)

Protect a CA's private key Offline root in an HSM

Encrypt for a low-power IoT device ECC (smaller keys, less computation)

Protect data against future quantum attacks AES-256 plus migration to ML-KEM and ML-DSA Chapter 7 covers cryptographic vulnerabilities—weak algorithms, poor key management, and implementation flaws—as an attack surface, and Chapter 12 applies these tools to data in its different states.

Chapter Summary

Symmetric encryption uses one shared key and is fast enough for bulk data; AES is the standard, while DES, 3DES, and RC4 are weak or deprecated. Asymmetric encryption uses a key pair: encrypt with the recipient's public key for confidentiality, sign with your private key for non-repudiation. Real systems use hybrid encryption.
RSA relies on factoring; ECC gives equivalent strength with much smaller keys. Diffie-Hellman enables key agreement, and ECDHE adds perfect forward secrecy, which TLS 1.3 requires. Key lengths are not comparable across algorithm types (AES-128 is roughly RSA-3072 or ECC-256).
Protocols such as TLS 1.2/1.3, IPsec (IKE, AH, ESP), SSH, S/MIME, and WPA3 protect data in transit; SSL and TLS 1.0/1.1 are deprecated.
Encryption levels—full disk, partition, volume, file, database (TDE), and record—protect against different threats. Choose the level that matches the threat.
PKI binds public keys to identities through certificates issued by CAs in a hierarchy anchored by a root of trust. Key escrow keeps recoverable copies of encryption keys under M-of-N controls.
Certificates may be third-party, internal, or self-signed. A CSR carries the public key, never the private key. Wildcard certificates cover one subdomain level. CRL, OCSP, and OCSP stapling report revocation.
Hashing is one-way and provides integrity; use SHA-2 or SHA-3, never MD5 or SHA-1 for security. Salting defeats rainbow tables, and key stretching (PBKDF2, bcrypt, scrypt, Argon2) slows brute force.
Digital signatures sign a hash with the private key, providing integrity, authentication, and non-repudiation.
Tools: TPM (per-device keys, measured boot), HSM (high-assurance key protection at scale), KMS (centralized key life cycle), and secure enclave (isolated processing).
Obfuscation includes steganography, tokenization, and masking.
Post-quantum: Shor's algorithm threatens RSA, DH, and ECC; Grover's halves symmetric strength, so use AES-256. NIST's ML-KEM, ML-DSA, and SLH-DSA are the first PQC standards, and harvest-now-decrypt-later makes migration planning urgent.

Key Terms

Plaintext; ciphertext; cipher; key; key length; work factor; Kerckhoffs's principle; symmetric encryption; block cipher; stream cipher; mode of operation; ECB; CBC; GCM; initialization vector (IV); AES; DES; 3DES; ChaCha20; RC4; asymmetric encryption; public key; private key; key pair; hybrid encryption; session key; RSA; elliptic curve cryptography (ECC); DSA; ECDSA; Diffie-Hellman; ECDHE; key exchange; key agreement; perfect forward secrecy (PFS); cryptoperiod; cryptographic agility; TLS; SSL; cipher suite; protocol downgrade; IPsec; IKE; AH; ESP; transport mode; tunnel mode; SSH; S/MIME; PGP; full-disk encryption (FDE); self-encrypting drive (SED); partition encryption; volume encryption; file encryption; transparent data encryption (TDE); record-level encryption; public key infrastructure (PKI); key escrow; key recovery agent; M-of-N control; certificate authority (CA); registration authority (RA); root CA; intermediate CA; chain of trust; root of trust; trust store; X.509; Subject Alternative Name (SAN); third-party certificate; self-signed certificate; certificate signing request (CSR); wildcard certificate; certificate revocation list (CRL); Online Certificate Status Protocol (OCSP); OCSP stapling; certificate pinning; hash; collision; MD5; SHA-1; SHA-2; SHA-3; HMAC; salt; pepper; rainbow table; key stretching; PBKDF2; bcrypt; scrypt; Argon2; digital signature; code signing; Trusted Platform Module (TPM); measured boot; hardware security module (HSM); FIPS 140-3; key management system (KMS); envelope encryption; secure enclave; trusted execution environment (TEE); obfuscation; steganography; tokenization; data masking; post-quantum cryptography (PQC); Shor's algorithm; Grover's algorithm; harvest now, decrypt later; ML-KEM; ML-DSA; SLH-DSA.

Review Questions

1. Alice wants to send Bob a confidential file so that only Bob can read it. Which key should be used to encrypt the file (or the session key that protects it)?

A. Alice's private key
B. Alice's public key
C. Bob's public key
D. Bob's private key

2. A security team wants to ensure that if an attacker later steals its web server's private key, previously recorded HTTPS sessions cannot be decrypted. Which solution BEST meets this requirement?

A. Increase the RSA key size to 4096 bits
B. Use ECDHE key exchange to provide perfect forward secrecy
C. Use a wildcard certificate
D. Hash all session data with SHA-256

3. An organization's database administrators must be able to manage and back up the customer database but must not be able to see customers' national ID numbers. Which encryption level is MOST appropriate?

A. Full-disk encryption
B. Transparent data encryption
C. Record-level (field-level) encryption
D. Volume encryption

4. A browser needs to determine, in real time, whether a website's certificate has been revoked, without downloading a large list. Which mechanism does it use?

A. CRL
B. OCSP
C. CSR
D. Key escrow

5. An attacker obtains a database of password hashes. Many users chose the same password, and the attacker uses precomputed tables to crack them quickly. Which measures would have been MOST effective in preventing this? (Select TWO.)

A. Salting each password with a unique random value
B. Using MD5 instead of SHA-1
C. Using a key stretching algorithm such as bcrypt or Argon2
D. Encoding the hashes with Base64
E. Storing the hashes in a self-signed certificate

6. A company needs a certificate that will secure www.example.com, mail.example.com, and portal.example.com, and it expects to add more hosts under the same domain. Which certificate type is MOST appropriate?

A. Self-signed certificate
B. Wildcard certificate for *.example.com
C. Code-signing certificate
D. Root CA certificate

7. An administrator generates a CSR for a new web server. Which of the following does the CSR contain? (Select TWO.)

A. The server's private key
B. The server's public key
C. The requested subject name and SANs
D. The CA's private key
E. The certificate revocation list

8. A company's laptops must protect their disk encryption keys so that the keys are released only if the boot process has not been tampered with. Which component provides this capability?

A. HSM
B. TPM
C. KMS
D. Token vault

9. A payment processor wants merchants to store a value that can be used for recurring billing but that has no mathematical relationship to the actual card number and would be useless if stolen. Which technique BEST meets this requirement?

A. Hashing with SHA-256
B. Steganography
C. Tokenization
D. AES encryption

10. A software vendor wants customers to be able to verify that an update came from the vendor and was not modified after release. Which solution should the vendor use?

A. Encrypt the update with the customers' public keys
B. Digitally sign the update with the vendor's private key
C. Publish an MD5 hash of the update on a forum
D. Compress the update with a password

11. A government agency is concerned that adversaries are recording its encrypted traffic today to decrypt it in the future with quantum computers. Which actions are MOST appropriate? (Select TWO.)

A. Replace AES-256 with 3DES
B. Begin migrating key establishment to ML-KEM, possibly in hybrid mode with ECDHE
C. Use AES-256 for symmetric encryption of long-lived sensitive data
D. Increase RSA keys to 8192 bits as the long-term solution
E. Disable all encryption until quantum-safe algorithms are available

12. An organization needs to protect the private key of its offline root certificate authority with tamper-resistant hardware validated to FIPS 140-3. Which tool should it use?

A. Secure enclave on an administrator's phone
B. Hardware security module
C. Software-based KMS without hardware backing
D. Steganographic container

Answers and Explanations

1. C. To provide confidentiality for Bob, encrypt with Bob's public key; only Bob's private key can decrypt. Alice's private key is used for signing, not confidentiality, and anyone with Alice's public key could "decrypt" something encrypted with it. Alice's public key would make the file readable only by Alice. Bob's private key is never available to Alice.
2. B. Ephemeral Diffie-Hellman (ECDHE) generates unique session keys that are discarded after use, so stealing the server's long-term private key does not expose past sessions—this is perfect forward secrecy. A larger RSA key does not help if the key itself is stolen. Wildcard certificates and hashing do not affect session key secrecy.
3. C. Record-level or field-level encryption keeps specific values encrypted even when the database is queried, so administrators who lack the key see only ciphertext. Full-disk, volume, and transparent data encryption all protect data at rest against theft of files or media but present decrypted data to anyone with legitimate access to the running database.
4. B. OCSP lets a client query a responder about a single certificate and receive a current status. A CRL requires downloading the full list and may be outdated between publications. A CSR is a request for a new certificate, and key escrow stores copies of keys.
5. A, C. A unique salt makes identical passwords produce different hashes and defeats precomputed rainbow tables. Key stretching makes each guess expensive, slowing brute-force cracking. MD5 is weaker than SHA-1, not stronger. Base64 is encoding, not protection. Certificates do not store password hashes.
6. B. A wildcard certificate for *.example.com covers any host at that subdomain level, including future ones. A self-signed certificate would generate browser warnings for public users. Code-signing certificates are for software, and a root CA certificate is not issued to web servers.
7. B, C. A CSR contains the requester's public key and the requested identity information, and it is signed with the private key to prove possession. The private key never leaves the requester. The CA's private key and the CRL are not part of a CSR.
8. B. A TPM measures the boot process into platform configuration registers and seals keys so they are released only when the measurements match the expected values. HSMs and KMS services manage keys for applications and services at scale but do not perform per-device measured boot. A token vault supports tokenization.
9. C. Tokenization substitutes a random token with no mathematical relationship to the card number, with the mapping held in a secure vault. Hashes of card numbers can be brute-forced because the input space is limited. Steganography hides data rather than replacing it. AES ciphertext can be decrypted by anyone who obtains the key.
10. B. A digital signature created with the vendor's private key lets customers verify origin and integrity using the vendor's public key. Encrypting with customers' public keys provides confidentiality, not proof of origin. An MD5 hash on a forum uses a broken algorithm and an untrusted channel. Password-protected compression does not prove who created the file.
11. B, C. Migrating key establishment to ML-KEM (often in a hybrid with ECDHE) addresses the quantum threat to today's key exchange, and AES-256 retains adequate strength even against Grover's algorithm. 3DES is weaker than AES. Larger RSA keys do not resist Shor's algorithm in the long term. Disabling encryption would expose data immediately.
12. B. HSMs are tamper-resistant, FIPS-validated devices designed to protect high-value keys such as CA signing keys. A phone's secure enclave is not an appropriate or controlled place for an enterprise root CA key. A software-only KMS lacks the required hardware tamper resistance, and steganography only hides data.

P A R T 2
Part 2: Threats, Vulnerabilities, and Attacks
Domain 2.0 — 24% of the exam

This part covers the adversary side of security: how threats and vulnerabilities are characterized, scored, and prioritized; who attacks organizations and why; the vectors and attack surfaces they exploit; the indicators that reveal malicious activity in progress; and the new threats and weaknesses that come with the use of artificial intelligence. It is the most heavily weighted domain after security operations, and many scenario questions elsewhere on the exam assume you can recognize the threats described here.