Objective 1.4: Explain the importance of using appropriate cryptographic solutions

Cert: CompTIA Security+ (SY0-701) Domain: 1.0 General Security Concepts Weight: ~12% of SY0-701 (Domain 1 total) Depth: Explain. Be able to define PKI (Public Key Infrastructure), describe encryption levels and algorithms, name the parts of a certificate chain, and explain hashing, salting, key stretching, and digital signatures in plain English.

What this objective tests

You should be able to explain what cryptography does in plain English, distinguish symmetric from asymmetric encryption, walk a certificate chain from root CA down to the end-entity certificate, and pick the right tool (TPM, HSM, secure enclave) for the job. You should also be able to define hashing, salting, and key stretching without confusing them with encryption. This is a heavy domain because every later Sec+ topic (data protection, IAM, secure communications, incident response) assumes you can speak about keys, certificates, and signatures fluently.

Key facts

Symmetric vs asymmetric encryption

Symmetric encryption uses one key for both lock and unlock. Same key on both ends. It is fast and good for bulk data like disk encryption and large files. AES (Advanced Encryption Standard) is the modern workhorse. Common key sizes: 128, 192, 256 bits.

Asymmetric encryption uses a key pair. The public key locks. The private key unlocks. Anyone can lock with a published public key. Only the holder of the matching private key can unlock. RSA and ECC (Elliptic Curve Cryptography) are the common asymmetric algorithms. ECC achieves the same security as RSA with smaller keys, which is why mobile devices and modern TLS prefer it.

Real systems mix both. TLS (Transport Layer Security) uses asymmetric crypto to safely share a symmetric session key, then switches to symmetric for the bulk traffic. The handshake is slow but secure. The session is fast.

Encryption levels

Encryption can be applied at many layers. The level tells you what is protected and when.

Key exchange and algorithms

Diffie-Hellman is the original idea behind safe key exchange over an open channel. Two parties pick parameters in public, perform separate math privately, and end up with a shared secret an eavesdropper cannot recover. Modern variants like ECDHE (Elliptic Curve Diffie-Hellman Ephemeral) add forward secrecy: a captured session cannot be decrypted later even if the long-term private key leaks.

Key length matters. Longer keys are harder to brute force but slower to use. AES-256 is the strong-symmetric default. RSA-2048 is the floor for asymmetric work, with RSA-3072 or ECC-P256 the modern minimums for new systems.

Tools: TPM, HSM, secure enclave, KMS

If a question describes a single laptop, the answer is usually TPM. If a question describes a whole CA or a bank, the answer is HSM. If a question describes an iPhone or a MacBook biometric, the answer is secure enclave. If a question describes cloud key rotation, the answer is KMS.

Hashing

A hash is a one-way function. Same input gives the same output every time. Different input gives a different output. The output is fixed length regardless of input size. Hashing is not encryption. There is no key. You cannot reverse a hash to recover the original input.

Salting and key stretching

When a system stores user passwords, it hashes them. A salt is random bytes added to the password before hashing. Two users with the same password get different stored hashes because they have different salts. Without a salt, attackers can use a rainbow table (precomputed hash lookup) to reverse the hash quickly.

Key stretching algorithms hash a password thousands or millions of times. This slows down brute force without slowing down the user noticeably. Common choices: PBKDF2 (Password-Based Key Derivation Function 2), bcrypt, and scrypt. Argon2 is the modern preferred option in new systems, though PBKDF2 still dominates Windows and many compliance-driven stacks.

Digital signatures (re-anchor from SP-1.2)

A digital signature proves both who sent a message (authenticity) and that the message was not changed (integrity). The sender hashes the message, encrypts the hash with their private key, and attaches the encrypted hash as the signature. The receiver decrypts the signature with the sender public key to get the hash, then recomputes the hash from the message. If the two hashes match, the message is authentic and intact. Because only the sender holds the private key, the sender cannot credibly deny sending it. That is non-repudiation.

SP-1.2 introduces the concept. SP-1.4 explains the mechanics. PKI is the system that makes digital signatures trustworthy at internet scale by binding public keys to verified identities through certificates.

PKI and certificates

A certificate binds a public key to an identity (a domain name, an organization, or a device). A CA (Certificate Authority) signs the certificate to prove the binding is real. Browsers and operating systems ship with a trust store of root CAs. All trust flows down from those roots.

The chain has three levels:

A CSR (Certificate Signing Request) is the file an admin sends to a CA to ask for a certificate. The CSR carries the public key and identity details. The private key stays on the server. The CA verifies, signs, and returns the certificate.

Revocation matters because certificates can be compromised, retired, or misissued before they expire. Two mechanisms exist:

Obfuscation: steganography, tokenization, data masking

Obfuscation hides data without using classical encryption.

• Steganography. Hide a message inside another file like a picture or audio file. The host file looks normal. The hidden data is visible only to someone who knows the trick. Used by both defenders (covert channels) and attackers (data exfiltration).
• Tokenization. Replace sensitive data with a non-sensitive substitute (a token). The mapping lives in a separate, well-protected vault. Common in payment systems where merchants store tokens, not card numbers, so a breach exposes nothing useful.
• Data masking. Scramble or partially hide values for display or testing. Showing only the last four digits of a credit card on a receipt is data masking.

Obfuscation buys time and reduces blast radius. It is not a substitute for strong encryption.

Blockchain

Blockchain is an open, append-only public ledger. Each block contains a hash of the previous block, so the chain detects tampering automatically. Anyone can verify history because the hashes link together. The most visible uses are cryptocurrencies, supply-chain attestations, and some PKI experiments. Sec+ asks for the concept and the role of the chained hashes, not implementation depth.

Common gotchas

• Calling the public key the secret one. The private key is the secret. The public key is published in the certificate and printed in CT (Certificate Transparency) logs. Flip the roles and every PKI question goes wrong.
• Treating hashing as encryption. Hashing has no key and no decrypt operation. SHA-256 a password and you cannot get the password back. The lookup attacks (rainbow tables, dictionary attacks) work by precomputing or guessing, not by reversing.
• MD5 confusion. MD5 is broken for security purposes (signatures, password hashing). It is still around for fast non-security checksums and legacy compatibility. Sec+ wants you to know it should not be used for security.
• Symmetric vs asymmetric speed. Symmetric is fast and shares keys badly. Asymmetric is slow and shares keys well. Real systems use asymmetric to bootstrap and symmetric to run.
• Self-signed is not automatically bad. Self-signed certificates are fine on an internal CA inside a controlled domain. They are risky on the public internet because there is no third-party verification of identity.
• CRL vs OCSP. CRL is a downloaded list. OCSP is a real-time lookup. Both check revocation. OCSP stapling lets the server pre-fetch the response and attach it to the TLS handshake, which speeds clients up.
• Wildcard scope. A wildcard for star dot example dot com covers shop.example.com but not store.shop.example.com. One level of subdomain only. A single private key now protects every subdomain, so the blast radius widens if it leaks.
• Salt vs pepper. A salt is unique per user and stored alongside the hash. A pepper is a secret value applied to all hashes and stored outside the database. Salts are required. Pepper is an additional layer some systems use.
• TPM vs HSM. TPM is a chip on one device. HSM is an appliance protecting many keys for a whole organization. Both are tamper-resistant. The scale and price are different.
• Key escrow caution. Key escrow stores a copy of a key in case of recovery. It is sometimes mandated, sometimes forbidden, and always a governance question. Sec+ wants you to know it exists and that policy controls when it is used.

Real-world context

A SOC Tier 1 analyst opens a ticket: TLS handshake failures across the customer-facing site after the 6:30 AM patch window. The analyst checks the cert with openssl s_client and sees the end-entity cert is fine but the intermediate CA expired this morning. Every cert that depends on that intermediate broke at the same moment. The fix is to push the renewed intermediate to the web servers and reload the TLS configuration. The deeper question (why was no one watching the intermediate expiration date) becomes a process gap and a candidate for the next gap analysis. This is the kind of ticket entry-level analysts see in week one.

Let's Encrypt is a good worked example for how PKI runs at internet scale. Let's Encrypt is a free CA that issues short-lived (90-day) certificates and expects them to be renewed automatically by clients like Certbot. The short lifetime means a compromised cert ages out quickly and forces operators to automate. Certificate Transparency logs publish every cert Let's Encrypt issues, so anyone can audit what certs exist for their domain. A misissued or rogue cert shows up in the public log within hours.

A small-business example: a managed-services provider sets up a new client's mail server and generates a CSR on the mail box. The provider sends the CSR to a public CA, gets the signed cert back, installs it, and ties the renewal to a calendar reminder. Six months later, a phishing attempt spoofs the client's domain. The provider checks Certificate Transparency, sees no matching cert was issued, and confirms the email signature is fake. The whole defense relied on PKI working as advertised: public CA, public log, private key never leaving the mail server, and signature trust flowing down from the root.

Sources

• CompTIA Security+ SY0-701 Exam Objectives, Section 1.4
• NIST SP 800-57, Recommendation for Key Management
• NIST SP 800-131A, Transitioning the Use of Cryptographic Algorithms and Key Lengths
• NIST SP 800-63B, Digital Identity Guidelines, Authentication
• IETF RFC 5280, X.509 Public Key Infrastructure Certificate and CRL Profile
• IETF RFC 6960, OCSP
• Let's Encrypt operational documentation for short-lived public CA practice