Security+ SY0-801 Cryptography: PKI, Certificates, Encryption and Hashing

Symmetric encryption uses one shared secret key to both encrypt and decrypt; asymmetric encryption uses a mathematically linked key pair, where what one key encrypts only the other can decrypt. Symmetric ciphers such as AES are fast and produce ciphertext about the size of the plaintext, so they do the bulk work. Their weakness is key distribution: both parties must already hold the same secret, and getting it to the other side safely is the problem. Asymmetric algorithms such as RSA and elliptic-curve cryptography (ECC) solve distribution, because the public half can be shared openly, but they are far slower and RSA can only process small blocks.

The key-count row shows how badly symmetric schemes scale. Symmetric keys grow with the number of pairs that must talk privately, so the count rises roughly with the square of the group size: a team of 10 already needs 10 x 9 / 2 = 45 keys, and every new member adds a key for each existing member. Asymmetric keys grow with the number of people: each person holds one key pair (two keys), because anyone can encrypt to a member's published public key, so the same team of 10 needs 20 keys.

Hybrid encryption

Real systems combine the two, each doing the job it is good at. The sender generates a random symmetric session key, encrypts the data with it, then encrypts (wraps) that short key with the recipient's public key. Only the recipient's private key can unwrap the session key, so no secret had to be shared in advance, and the expensive asymmetric operation runs once on a few dozen bytes however large the data is. TLS, S/MIME and PGP all work this way: asymmetric cryptography moves or agrees the key, symmetric cryptography moves the data.

Public key infrastructure (PKI) is the set of key pairs, certificates, certificate authorities and policies that let people trust whose public key is whose. Every asymmetric operation follows two rules, and most questions on key roles come down to choosing the right owner and the right half:

The public key is meant to be published: distributing it in a certificate, a directory or a key server lets anyone send you encrypted data or verify your signatures. The private key must never leave its owner. Using the wrong half breaks the goal: something "encrypted" with the sender's private key can be reversed by anyone holding the sender's public key, so it gives no confidentiality, and encrypting to your own public key locks the recipient out. To send a message that is both confidential and provably yours, do both: sign with your private key and encrypt with the recipient's public key.

Because only the private key decrypts, losing it loses the data. The public half keeps working for senders after the private half is gone, so data can go on being encrypted to a key that nobody can use any more; a user whose smart card is wiped, for example, can no longer open any mail encrypted to that card's key. Private keys of encryption key pairs therefore need protected backups or escrow.

Key escrow

Key escrow means a trusted third party (or a tightly controlled internal custodian) holds copies of keys so encrypted data can still be recovered when the original key, or its holder, is unavailable: a failed device, a forgotten passphrase, or a lawful demand for access. Its purpose is recovery of data that already exists; it does not replace keys, agree new keys or strengthen passwords.

Escrow has a cost: the escrow store concentrates many users' keys in one place, so whoever compromises or abuses it can decrypt everyone's data. It needs strong access control, dual control and auditing. It also has a limit on which keys belong there. Escrow the keys that decrypt data (the private keys of encryption key pairs), so data stays recoverable; never escrow signing keys, because a signature proves origin only if the signer alone holds the key; a copy in escrow would let the custodian sign as that person and destroy non-repudiation. The two rules can only both be met when a person's encryption key and signing key are different keys, which is why PKI designs commonly separate the two purposes.

A digital certificate binds a public key to an identity (such as a hostname, person or organization) and is signed by a certificate authority (CA) that vouches for that binding. A client trusts a certificate only if it can build a chain from it, through any intermediate CAs, to a root certificate it already holds in its trust store. That root, a self-signed certificate preinstalled by the operating system or browser vendor (or pushed by an administrator), is the root of trust: revocation data and other checks happen along the chain, but they cannot create trust on their own.

Why intermediates exist

Public CAs issue server certificates from intermediate (subordinate) CAs, not directly from the root. That keeps the root's private key out of day-to-day use, typically powered down in an offline HSM and brought out only to sign intermediates or revocation lists; if an intermediate is compromised it can be revoked and replaced while the root, and every trust store that contains it, survives. A compromised root would have to be removed from trust stores everywhere. Roots are valid for many years; intermediates and server certificates for much less.

The server is responsible for sending the intermediate certificates along with its own (the "full chain"). Clients differ in how they cope when it does not: some fill the gap from a cache of intermediates seen before, or download the issuer certificate from the address in the certificate's Authority Information Access field, and others simply fail validation. An incomplete chain therefore produces errors on some clients and not others, and a site that looks fine in one browser has not proved its chain is complete; chain-checking tools test what the server actually sends.

Whoever controls a trusted root controls trust

Any certificate that chains to a root in the trust store is accepted for whatever name it carries. Organizations use this deliberately: a TLS-inspection proxy holds a CA whose root is pushed to managed devices, so it can issue a certificate for each site on the fly, decrypt the traffic for inspection and re-encrypt it, with no browser warning. The same mechanism in hostile hands works the same way, which is why adding roots to trust stores must be controlled and monitored. Trust-store integrity is a security control in its own right.

Self-signed, internal CA and third-party certificates

The deciding question is whose devices must trust it. A customer-facing site needs a public third-party CA, because visitors' devices already hold its root and need no configuration. For internal systems on managed devices, an internal CA is usually best: push its root once and every certificate it issues is trusted, and it can issue for any name the organization uses. That matters for private names: public CAs issue only for registered domains whose control they can validate, so hosts named under a private suffix (such as .lan or .local) can get a widely trusted certificate only from an internal CA. Self-signed certificates are their own trust anchors, so each one must be trusted separately on every client, which does not scale.

A certificate signing request (CSR) is the message a requester sends to a CA asking for a certificate: it contains the public key and the subject details (such as the common name and subject alternative names) and is signed with the matching private key to prove possession. CSR generation follows a fixed order:

1. Generate the key pair where the key will live: on the server, or inside its HSM.
2. Build the CSR from the public key and the subject details, and sign it with the private key.
3. Send only the CSR to the CA. The CA validates the requester's control of the names and returns a certificate binding that public key to the identity.
4. Install the certificate next to the private key that already exists on the host.

The CSR holds only public information, so it can be emailed or pasted into a web form; the private key never travels as part of the process. Two consequences follow. First, a certificate contains only the public key, so it is useless to a service without its matching private key: when a service moves to new hardware, either the key pair moves with the certificate (for example as a password-protected PKCS#12/.pfx bundle) or a fresh key pair and CSR are created at the destination and a new certificate issued. Second, the rule extends to hardware: a smart card or HSM that must hold a key creates the key pair itself and signs the CSR internally, so the key is never exported in any form.

Wildcard and SAN certificates

A wildcard certificate uses an asterisk as the leftmost label, such as *.example.net, and matches exactly one label in that position: mail.example.net and intranet.example.net match, and so does a host added after issuance. It does not match the bare (apex) domain example.net, nor names two or more labels deep such as a.b.example.net. Public CAs allow the asterisk only once, as the entire leftmost label.

A subject alternative name (SAN) certificate lists specific names, and modern certificates carry all their names in the SAN field. SAN entries and wildcards combine freely: a wildcard is just one entry in the SAN list, so a single certificate can carry the apex name, a wildcard and any specific deeper names side by side.

Wildcards carry a risk: every server that holds the wildcard's private key can impersonate every matching subdomain. The more servers share one wildcard key, the more places it can leak from, and the weakest of them sets the security of every name the wildcard covers; a single leak means revoking the certificate and rekeying every host that used it. Separate certificates (or keys) per service limit that blast radius.

Revocation withdraws trust in a certificate before it expires, typically because its private key was compromised or its holder left, and clients learn about it through a certificate revocation list (CRL) or the Online Certificate Status Protocol (OCSP).

The weakness of CRLs is latency. A client keeps accepting a revoked certificate until it holds a list published after the revocation, so the exposure window is roughly the publication interval plus however long clients cache each list. Only two things shorten it: publishing (and fetching) lists more often, or checking status at connection time with OCSP.

OCSP stapling and soft-fail

With OCSP stapling, the web server periodically fetches its own CA-signed OCSP response and includes it in the TLS handshake. Each client receives its status answer inside the handshake instead of looking it up separately, so connections are not held up by an extra lookup, the responder's load drops to one request per server, and the CA no longer learns each user's browsing. The response is still signed by the CA, so the server cannot forge a "good" status. A certificate can be marked must-staple, telling clients to refuse a connection that arrives without a stapled response.

Revocation only protects users if clients act on it. Many clients soft-fail: if no stapled response is sent and the OCSP responder cannot be reached, they treat the missing answer as a pass and connect. Revocation then protects only against attackers who cannot interfere with status checks; anyone able to suppress the answer suppresses the revocation. Hard-fail behaviour, or must-staple certificates, make a missing answer a failure instead.

Practice is shifting: the CA/Browser Forum made OCSP optional for publicly trusted TLS certificates, and some public CAs (Let's Encrypt among them) have stopped running OCSP and publish CRLs only, while browsers increasingly push revocation data to clients themselves. The concepts above, and both mechanisms, remain exactly what the exam objective lists.

The encryption level is the scope at which data is encrypted, and it decides who the encryption protects against: storage-level encryption protects data when the device is off or stolen, while file-, database- and record-level encryption keep data protected from people and systems that can use the running device.

Two patterns explain most scenarios. First, every storage-level layer decrypts transparently once unlocked. While a server's encrypted volume is mounted, any process or user with file permissions reads plaintext; the encryption matters again only when the volume is dismounted or the machine is off. Storage-level encryption also stays with the storage: a file copied to a USB stick, a cloud share or an attachment is no longer covered by the disk it came from, and transport encryption covers only one network hop. Protection that must follow the data wherever it goes has to be applied to the file itself.

Second, to hide data from people who can legitimately query a database, encrypt the fields, not the storage. Transparent database encryption and every storage layer beneath it decrypt for any authorized session, so they cannot separate one authorized group from another. Encrypting a sensitive column, such as salaries in an HR database, with keys released only to the application that needs it keeps the values readable to that application and opaque to everyone else who can query the table, administrators included. Tokenization, covered with obfuscation below, is the alternative when systems need to keep referring to a value without holding it at all.

Transport (communication) encryption protects data while it moves across a network, and the right protocol depends on what has to be protected: one application's sessions, a remote shell, mail between servers, or every packet between hosts or networks.

Two questions decide most choices. First, scope: does every packet between hosts or networks need protecting regardless of application (IPsec, which needs no application support), one application's sessions (TLS, which the application must support), interactive administration of one host (SSH), a plaintext protocol upgraded in place (STARTTLS), or the message itself after delivery (S/MIME or PGP)? Second, what the network allows: IPsec negotiates keys with IKE on UDP 500 and uses UDP 4500 for NAT traversal, while TLS-based VPNs run over TCP 443, which almost every network permits outbound. Legacy cleartext protocols (Telnet, FTP, HTTP, LDAP, SNMPv1/v2c) each have an encrypted replacement in the table above.

Key exchange and forward secrecy

Key exchange is how two parties end up with the same symmetric session key. With RSA key transport, one side encrypts a key to the other's public key. With Diffie-Hellman (DH) and its elliptic-curve form ECDH, each side combines its own private value with the other's public value and both compute the same secret, which never crosses the network. Its security does not depend on hiding the exchanged values: they are public by design, and computing the shared secret from them alone is infeasible. Diffie-Hellman is key agreement, not a cipher: it encrypts nothing itself.

Two facts about DH matter in scenarios:

• Ephemeral exchanges give forward secrecy. With DHE/ECDHE, fresh values are generated for every session and discarded afterwards, and the server's long-term private key only signs the exchange. That key's job is therefore authentication, not secrecy: if it is compromised, the damage runs forward (someone can pose as the server until the certificate is revoked and replaced), not backward, because the discarded session secrets cannot be rebuilt from it. With static RSA key transport, by contrast, the same long-term key decrypts every recorded session. TLS 1.3 removed static RSA key transport, so its certificate-based handshakes always use (EC)DHE.
• Unauthenticated DH resists eavesdroppers, not impostors. If neither side verifies who sent the exchange values, which is common on simple embedded or ad hoc links, an on-path attacker can run a separate exchange with each party and relay traffic, holding both keys. Signing the exchange with certificate-backed keys, as TLS does, closes that gap.

The algorithm decides what a cryptographic operation does (encrypt, agree keys, sign or hash), and the key length decides how hard it is to brute-force; strength must be compared within an algorithm family, not across families.

Key length is exponential

Each extra key bit doubles the number of possible keys. Ten extra bits multiply the keyspace by about a thousand, and 64 extra bits (AES-128 to AES-192) multiply it by 2^64; key length and brute-force effort are related exponentially, never linearly. The performance cost of a longer AES key is small by comparison: AES runs 10, 12 or 14 rounds for 128-, 192- and 256-bit keys, while the block size, and therefore the ciphertext size, is the same for every key length.

Comparable strength across families

Asymmetric keys must be much longer than symmetric keys for the same strength, and ECC needs far shorter keys than RSA. NIST's comparison (SP 800-57) puts roughly 128-bit symmetric strength at RSA-3072 or a 256-bit elliptic curve; RSA-2048 is about 112-bit strength, and RSA-1024 is too weak for any new use. Because ECC reaches the same strength with smaller keys and lighter computation, it is favoured wherever CPU, memory, power or bandwidth is scarce: smart cards, phones, embedded and IoT hardware, and high-volume TLS servers. Key length only compares strength within a family; it never turns one kind of algorithm into another.

Looking ahead, NIST published its first post-quantum standards in 2024 (ML-KEM for key establishment, ML-DSA and SLH-DSA for signatures), because a large quantum computer would break RSA, DH and ECC. Symmetric ciphers and hashes are far less affected; longer keys such as AES-256 keep a comfortable margin.

A hash function turns input of any size into a fixed-length digest that cannot be reversed, so it proves integrity: the same input always gives the same digest, and any change gives a completely different one. The properties that matter are determinism, the avalanche effect (a one-bit change yields an unrelated digest), one-way operation, fixed output length and no key. SHA-256 always produces 256 bits, which display as 64 hexadecimal characters, whether the input is a single character or a terabyte; MD5's 128 bits display as 32. Because a hash is one-way, it suits values that only ever need to be compared (passwords, file fingerprints), never values someone must read back.

Know what "broken" means. MD5's practical break is a collision: an attacker who controls both inputs can craft two different files with the same digest, for example a harmless file and a malicious twin, and swap them after the harmless one is approved or signed. Hash security has three distinct properties: collision resistance (no two inputs with the same digest), second-preimage resistance (no new input matching a given file's digest) and preimage resistance (no input recoverable from a digest). Losing the first is enough to retire an algorithm for signatures and certificates, which is why MD5 and SHA-1 have given way to SHA-256 or SHA-3. Non-cryptographic checksums such as CRCs catch accidental corruption but are trivial to forge.

Salting

Unsalted password hashes are deterministic: two users with the same password get the same hash, whatever the algorithm, and attackers can use precomputed rainbow tables. A salt is a unique random value generated for each account and hashed together with the password. Two users with the same password then have different hashes, which hides password reuse and makes precomputed tables useless, because a table would be needed for every salt.

A salt is not a secret: it is stored in the clear next to the hash, and its value lies in being unique, not hidden, so a database breach that includes the salts leaves that benefit intact. Its limit is that it adds no work per guess: an attacker can still try likely passwords against each account using that account's salt, so weak passwords still fall. Making every guess expensive is the job of key stretching (bcrypt, PBKDF2, scrypt, Argon2). Some systems also add a pepper, a secret value kept outside the database (for example in an HSM), as a separate layer.

Digital signatures

A digital signature is a hash of the content signed with the signer's private key. The verifier recomputes the hash and checks the signature with the signer's public key, usually taken from a trusted certificate. Signing does not encrypt the content; the document stays readable.

The difference is who can produce the value. A plain hash can be computed by anyone, so a hash published through the same channel as the file proves nothing if that channel is compromised; only a hash obtained from a separate trusted source helps. A signature can be produced only with the private key, so it survives an untrusted distribution channel. A failed verification against a trusted key means the bytes being checked are not the bytes that were signed: usually the content was altered after signing, and otherwise the verifier is using a different algorithm or format than the signer.

Cryptographic tools are the hardware and services that generate, store and use keys so the keys are not exposed to ordinary software. The objective lists "tools" without sub-items; these four are the standard examples and are told apart by where the key lives and who uses it.

Two properties separate them in practice. A TPM is a small, slow chip: it measures, seals and releases keys, while the bulk encryption of data runs on the main processor or in a self-encrypting drive. And keys can be generated inside an HSM or a secure enclave as non-exportable: software asks the hardware to perform an operation with the key, and the key material itself never leaves the device (secure-enclave keys always work this way; many HSMs also allow wrapped export for backup or clustering when a key's attributes permit it).

Obfuscation

Obfuscation makes data or code hard to notice or understand without relying on a secret key, so enough effort can undo it; encryption's protection rests on a key, without which the ciphertext stays unreadable. Common forms:

• Steganography hides the very existence of data inside another file, such as an image or audio file. Encryption hides what data says but not that it exists: ciphertext does not look like an ordinary photo. Legitimate uses include watermarking; attackers use it to hide malware payloads, command traffic or stolen data inside innocent-looking media.
• Code obfuscation renames identifiers and restructures code so it still runs unchanged but is hard for people to read, for example a mobile app distributed to the public, where the code must run on devices the vendor does not control. It slows reverse engineering; it does not stop it.
• Data masking hides part of a value. Dynamic masking hides it when it is shown, such as displaying only the last four digits of an account number, while the full value is still stored; static masking permanently replaces the real values in a copy made for testing or analytics.
• Tokenization replaces a sensitive value with a random substitute, a token, and keeps the real value only in a separate, tightly controlled token vault.

Tokenization compared with encryption, hashing and masking

A token has no mathematical relationship to the value it replaces, so nothing about the token, and no key, turns it back into the original; only a lookup in the vault can. That is what sets it apart from its near-twins:

The practical pattern: when a business must keep using a sensitive identifier, for example a health insurer that bills against members' national ID numbers, it can send each value to a tokenization service, store only the returned tokens in its own claims, reporting and support systems, and let the service detokenize whenever the real value is genuinely needed. A breach of those systems then exposes tokens that are worthless outside the vault. Hashing fits a different need, checking a value without ever reusing it, and short, structured identifiers make poor hash inputs anyway, because every possible value can be hashed and compared. Tokenization and masking also appear among the data-protection methods of objective 3.3.

Obfuscation raises the attacker's effort; it is not a security boundary and never a substitute for encryption.