Cryptography and PKI for SY0-701

Cryptography questions on Security+ SY0-701 are usually decision questions: which mechanism protects confidentiality, which mechanism proves integrity or origin, where keys should be stored, how certificates establish trust, and what happens when a certificate or key can no longer be trusted.

The existing cryptography fundamentals article covers public and private keys at a foundational level. This guide expands to the exam’s broader cryptographic solution set: symmetric and asymmetric encryption, hashing, salting, digital signatures, key exchange and storage, TPMs and HSMs, certificates, revocation, trust chains, and common data-protection use cases.

Cryptography should start with the security objective

Encryption protects confidentiality, hashing supports integrity checks, and digital signatures can support integrity, origin, and non-repudiation depending on the context. One mechanism can contribute to several goals, but the primary requirement should drive selection.

Security+ scenarios become easier when you ask what property the organization needs before choosing an algorithm or tool.

Symmetric encryption is efficient for protecting data

Symmetric algorithms use the same shared secret to encrypt and decrypt data. They are efficient for large amounts of data, but the secret must be distributed and protected.

That creates a key-management challenge: anyone who obtains the secret may be able to decrypt protected information.

Asymmetric cryptography separates public and private roles

Asymmetric systems use a related public and private key pair. The public key can be distributed broadly while the private key must remain protected.

This enables patterns such as digital signatures, certificate-based identity, and secure establishment of shared secrets without distributing one long-lived symmetric key to everyone.

Hybrid cryptography combines strengths

Many secure protocols use asymmetric cryptography to authenticate parties or establish shared material, then use symmetric encryption for the bulk data transfer.

This pattern exists because asymmetric operations are flexible but more computationally expensive, while symmetric algorithms are efficient for ongoing communication.

Hashing supports integrity without reversible encryption

A cryptographic hash maps input data to a fixed-size digest. Small changes in input should produce a very different digest, making hashes useful for integrity checks.

A hash is not encryption because there is no decryption key that recovers the original value.

Salting protects stored password hashes

A salt is random data combined with a password before hashing. Unique salts make identical passwords produce different stored values and reduce the usefulness of precomputed hash tables.

Salting does not make weak passwords strong, but it makes large-scale cracking less efficient.

Key stretching increases password-guessing cost

Key-stretching techniques deliberately make password-derived calculations more expensive so attackers cannot test guesses as quickly.

The defensive goal is to increase attack cost while keeping legitimate authentication practical.

Digital signatures use private keys to prove origin

A signer creates a signature with a private key, and others verify it with the corresponding public key. Signatures can show that content has not changed and that the holder of the private key produced the signature.

Protecting the signing key is critical. If the private key is compromised, the trust in new signatures is compromised too.

Key exchange establishes shared cryptographic material

Key-exchange mechanisms allow parties to agree on secret material over an untrusted network without sending the final shared secret directly.

Security depends on the chosen protocol, authentication of the parties, and protection against interception or downgrade.

TPMs and secure enclaves protect key material near the endpoint

Trusted Platform Modules and secure hardware enclaves can store or use sensitive keys so the raw private material is harder to extract from ordinary software.

These mechanisms are valuable for device identity, disk encryption, attestation, and other operations where key protection matters.

HSMs centralize high-assurance cryptographic operations

Hardware security modules can generate, store, and use keys in a protected environment and are commonly used for high-value signing, certificate authority, or payment-related operations.

They add cost and operational complexity, so the use case should justify the assurance level.

PKI binds public keys to identities

Public key infrastructure uses certificates, certificate authorities, trust chains, enrollment, revocation, and policies to help systems decide whether a public key should be trusted for a named identity.

PKI is therefore an identity and trust system built around cryptography, not merely a file format.

Certificate authorities anchor trust

A CA signs certificates according to its policy. Clients trust the certificate when they can build a valid chain to a trusted root and when the certificate meets hostname, time, and usage requirements.

Root CA protection is especially important because compromise can undermine trust in certificates issued beneath it.

CSRs support certificate enrollment

A certificate signing request contains identifying information and the public key to be certified, while the corresponding private key should remain protected by the requester.

The CA validates the request according to policy before issuing a signed certificate.

Revocation handles trust before expiration

Certificates sometimes need to be distrusted before their normal expiration because a key was compromised, an identity changed, or the certificate was issued incorrectly.

CRLs and OCSP are mechanisms used to communicate revocation status. The exam may test the difference between a certificate that is expired and one that is actively revoked.

Wildcard and self-signed certificates solve different problems

A wildcard certificate can cover multiple names within a defined namespace, reducing certificate count but increasing the impact if its private key is compromised.

A self-signed certificate can provide encryption but does not automatically establish trusted identity for other parties unless the certificate is distributed as a trust anchor.

Choose encryption at the right data layer

Security+ distinguishes full-disk, partition, file, volume, database, record, and transport encryption. Protect data where the threat exists and where authorized applications still need usable access.

Encrypting a disk protects lost hardware, but it does not prevent an authorized running application from reading the plaintext it legitimately accesses.

Key length and algorithm choice affect cryptographic strength

Longer keys can increase resistance to brute-force attacks, but the meaning of key length differs across algorithm families. Choose modern, approved algorithms and parameters rather than assuming a large number automatically means strong security.

Security+ scenarios may present an obsolete algorithm beside a current one; the correct choice usually follows current security practice and the stated compatibility requirement.

Data masking and tokenization protect information differently

Masking hides portions of data in displays or nonproduction use, while tokenization replaces a sensitive value with a substitute whose mapping is stored or managed separately.

Neither mechanism is simply encryption. Choose based on whether the original value must be recovered and which systems truly need access to it.

Steganography hides the existence of data

Steganography embeds information inside another medium so the presence of the hidden data is less obvious. This is different from encryption, which protects content even when the ciphertext is visible.

Security questions may contrast the two goals: concealment of existence versus confidentiality of content.

Key escrow supports controlled recovery

Key escrow stores or protects a recovery copy of cryptographic material so authorized parties can regain access under defined circumstances.

Escrow increases availability but creates a sensitive trust point. Access to escrowed material should be tightly controlled and audited.

Certificate pinning changes ordinary trust behavior

Some applications expect a specific certificate or public key rather than accepting any certificate that chains to a trusted CA. This can strengthen resistance to interception but can complicate certificate rotation and inspection.

When decryption or proxying causes one application to fail while normal browsers work, a stricter certificate expectation may be relevant.

Cryptographic failure often comes from key management

Strong algorithms provide little protection if private keys are copied into source code, shared broadly, never rotated, or retained after they should be destroyed.

Key generation, storage, distribution, rotation, revocation, backup, and destruction belong in the cryptographic lifecycle.

Certificate expiration and revocation answer different questions

Expiration means the certificate has reached the end of its intended validity period. Revocation means the issuer or relying environment has decided the certificate should no longer be trusted before that date.

When troubleshooting, identify which condition applies because renewal and incident response may follow different paths.

Cryptographic controls need rotation and retirement plans

Algorithms, keys, certificates, and trusted roots change over time. Systems should support replacement before compromise, expiration, or deprecation forces an emergency migration.

Lifecycle planning is part of cryptographic security because long-lived dependencies can keep obsolete mechanisms in service far beyond their safe period.

Protect root trust separately from ordinary certificates

Root CA private keys and trust anchors affect many downstream certificates. They therefore deserve stronger protection, restricted use, and carefully controlled lifecycle procedures.

A compromised root can undermine a large trust domain, which is why PKI architecture separates root authority from day-to-day service certificates.

Exam scenarios reward trust-path reasoning

When a TLS or certificate scenario fails, check the certificate’s name, validity period, chain, issuing CA, revocation state, intended use, and whether the client trusts the root.

That systematic trust-path model is more reliable than memorizing one certificate error for one technology.