Security+ 801 Countdown, T-34: Cryptography Adds Protocols and Stops Naming TPM, HSM, and Key Stretching

A cryptographic solution is the whole arrangement that turns a mathematical primitive into protection for real data: the algorithm, the key that drives it, the hardware or software that holds that key, and the protocol that tells two parties how to use all of it on a live connection. An algorithm such as AES is only a function; it becomes useful once a protocol such as TLS decides which algorithm to run, how the two ends agree on a key, and what to do when the other side offers something weaker. Most practical failures happen in that surrounding machinery rather than in the primitives, which is why one objective has to cover protocols, key sizes, hashing, and key-holding hardware together.

In SY0-801 this material sits under objective 1.3, “Explain the importance of using appropriate cryptographic solutions,” which newly lists Protocols as the first entry under Encryption (CompTIA 2025). The same objective covers Algorithms, Key length, Hashing algorithms, Salting, Digital signatures, Tools, Obfuscation, Certificates, and PKI, and it expects working knowledge of TLS, IPsec, AES, RSA, ECC, and SHA-2 behind those general headings. This post takes them in the order a packet meets them: protocol, algorithms and key strength, hashing, and finally the hardware and password-storage practices that keep keys and secrets from leaking.

Protocols: putting algorithms on the wire

A cryptographic protocol is an agreed sequence of messages by which two parties choose algorithms, establish keys, authenticate each other, and then protect the traffic that follows. The objective gives Protocols no examples; TLS and IPsec are the anchors the document itself supplies, with OCSP under Certificates and “Request for comments (RFC)” under Standards in 5.1 (T-7). SSH and WPA3 are fair examples even though the objectives do not name them. Do not confuse this Protocols entry with the 4.4 “Protocols” group (NetFlow, SNMP, syslog, SCAP), which is about monitoring.

TLS 1.3 and the rules for TLS 1.2

Transport Layer Security (TLS) is the protocol beneath HTTPS and most other secured application traffic. A TLS connection begins with a handshake in which the client and server agree on a cipher suite, a named bundle of the key exchange method, the authentication method, the bulk cipher, and the hash. TLS 1.3 removed static RSA and static Diffie-Hellman key exchange, so “all public-key based key exchange mechanisms now provide forward secrecy” (Rescorla 2018). Forward secrecy means that session keys are derived from ephemeral values discarded after the handshake, so a server private key stolen later cannot decrypt traffic recorded earlier. Every remaining cipher is AEAD (authenticated encryption with associated data), which produces an integrity tag as part of encryption instead of relying on a separate MAC: AES-GCM, ChaCha20-Poly1305, or AES-CCM. A full handshake takes one round trip, and everything after ServerHello is encrypted, including the server certificate. Suite names shrank to the AEAD and the hash, e.g., TLS_AES_128_GCM_SHA256. TLS 1.2 names all four parts: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 is ECDHE key exchange, RSA authentication, AES-128-GCM, and SHA-256.

Older versions are prohibited, not merely discouraged. RFC 8996 states “TLS 1.0 MUST NOT be used” and says the same of TLS 1.1 (Moriarty and Farrell 2021). RFC 9325 requires TLS 1.2, recommends TLS 1.3, and advises against static RSA suites (no forward secrecy) and CBC suites without encrypt_then_mac (Sheffer, Saint-Andre, and Fossati 2022). All of this is visible in one query to a live server, captured October 12, 2026 with OpenSSL 4.0.3 (lines trimmed):

$ openssl s_client -connect example.com:443 -servername example.com -tls1_3 </dev/null
Certificate chain
 0 s:CN=example.com
   i:C=US, O=SSL Corporation, CN=Cloudflare TLS Issuing ECC CA 3
   a:PKEY: EC, (prime256v1); sigalg: ecdsa-with-SHA256
   v:NotBefore: Sep 26 22:49:11 2026 GMT; NotAfter: Dec 25 22:56:35 2026 GMT
...
Peer signature type: ecdsa_secp256r1_sha256
Negotiated TLS1.3 group: X25519MLKEM768
---
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
...
Verify return code: 0 (ok)

$ openssl s_client -connect example.com:443 -tls1_1 </dev/null
...:error:0A0000BF:SSL routines:tls_setup_handshake:no protocols available:...

Reading the output top to bottom:

• The negotiated suite names only the AEAD (AES-256-GCM) and the hash (SHA-384), as every TLS 1.3 suite does.
• The group combines X25519 ECDHE with ML-KEM-768 (FIPS 203), a hybrid post-quantum key agreement standardized in RFC 10024 in August 2026 (Kwiatkowski et al. 2026).
• The leaf key is ECDSA P-256 (128-bit strength), valid about 90 days, inside the CA/Browser Forum’s 200-day maximum in force since March 15, 2026 (CA/Browser Forum 2026).
• The TLS 1.1 attempt fails in the client, because OpenSSL’s default security level 2 disables TLS 1.0 and 1.1. At security level 0, the same server still accepted TLS 1.1, a finding under RFC 8996.

IPsec: AH, ESP, modes, and IKE

IPsec is the protocol family that protects traffic at the IP layer, so it secures whatever rides above it without the application knowing. It has two protection protocols. Authentication Header (AH, IP protocol 51) authenticates packets without encrypting them, and because its integrity check covers header fields that address translation rewrites, it breaks under NAT; NIST discourages it (Barker et al. 2020). Encapsulating Security Payload (ESP, IP protocol 50) adds confidentiality and is mandatory to implement. Both are IP protocol numbers, not ports.

Each protection protocol runs in one of two modes. Transport mode protects only the payload and leaves the original IP header in place, so it works host to host and is incompatible with NAT. Tunnel mode wraps the whole original packet inside a new one, and it is required when either end is a security gateway (Kent and Seo 2005). Keys for either mode come from Internet Key Exchange: IKEv2 (RFC 7296) negotiates on UDP 500, or UDP 4500 for NAT traversal, and IKEv1 should not be used for new deployments.

Replacing cleartext protocols

Much of the “appropriate” in the objective title comes down to choosing the encrypted version of a service over the plaintext one:

Cleartext	Secure option	IANA port
Telnet (23)	SSH	22/tcp
HTTP (80)	HTTPS	443/tcp
LDAP (389)	LDAPS, or StartTLS on 389	636/tcp
SNMPv1 and v2c	SNMPv3 with USM privacy	161/udp
DNS (53)	DNS over TLS	853/tcp

For mail, RFC 8314 prefers implicit TLS (465 for submission, 993 for IMAP, 995 for POP3) over STARTTLS on 587; implicit TLS begins the session encrypted instead of upgrading a cleartext one. DNS over TLS encrypts the query; DNSSEC adds integrity and origin authentication but “is not designed to provide confidentiality” (RFC 4033). Private lookups call for the former, proof that an answer was not forged for the latter.

Algorithms, key length, and security strength

Key length is the number of bits in a key. Security strength is the work an attacker needs, expressed as the equivalent of brute-forcing a symmetric key of that many bits, and the two match only for symmetric ciphers. Key length is not security strength (Barker 2020, Table 2):

Strength (bits)	Symmetric	RSA or DH modulus	ECC key
80 or less	2TDEA	1024	160 to 223
112	3TDEA	2048	224 to 255
128	AES-128	3072	256 to 383
192	AES-192	7680	384 to 511
256	AES-256	15360	512 and up

So RSA-2048 is 112-bit strength, acceptable through 2030 under SP 800-57. Two NIST drafts, SP 800-131A Rev. 3 ipd and IR 8547 ipd, propose deprecating 112-bit RSA and ECC after 2030, and IR 8547 would disallow every quantum-vulnerable public-key algorithm after 2035 (Barker and Roginsky 2024; Moody et al. 2024). Those dates are proposals. FIPS 203, 204, and 205 (ML-KEM, ML-DSA, and SLH-DSA) were published August 13, 2024 (NIST 2024), and the X25519MLKEM768 group in the capture above is one of them in deployment, though nothing quantum appears in the SY0-801 objectives.

Mode matters too. A block cipher encrypts one fixed-size block at a time; a mode of operation is the rule for chaining blocks into a whole message. ECB leaks patterns because identical plaintext blocks encrypt identically; CBC needs an unpredictable IV and a separate MAC; GCM is AEAD, but its IV must never repeat under one key (SP 800-38D). When I teach this in ITN 260, the confusion is usually that “AES-256” gets treated as a complete answer, when the mode and the IV handling decide whether the ciphertext leaks.

Hashing algorithms and collision resistance

A hash function maps input of any length to a fixed-size digest. A cryptographic hash is one for which finding two inputs with the same digest (a collision) or recovering any input from a given digest (a preimage) is computationally infeasible. For hashing algorithms, the dividing line is collision resistance. MD5 lost it long ago (RFC 6151), and SHAttered, announced February 23, 2017, produced two different PDFs with one SHA-1 digest (Stevens et al. 2017). Checked against the two published files on October 12, 2026:

$ shasum -a 1 shattered-1.pdf shattered-2.pdf
38762cf7f55934b34d179ae6a4c80cadccbb7f0a  shattered-1.pdf
38762cf7f55934b34d179ae6a4c80cadccbb7f0a  shattered-2.pdf
$ shasum -a 256 shattered-1.pdf shattered-2.pdf
2bb787a73e37352f92383abe7e2902936d1059ad9f1ba6daaa9c1e58ee6970d0  shattered-1.pdf
d4488775d29bdef7993367d541064dbdda50d383f89f0aa13a6ff2e0894ba5ff  shattered-2.pdf

That is a collision, not a preimage: the researchers built two documents to share a digest rather than recovering a file from a digest. A signature over that digest cannot tell the two PDFs apart, which is why collision resistance matters for signing. NIST plans to finish moving off SHA-1 for all applications by December 31, 2030 (NIST 2022); use SHA-256, SHA-384, or SHA-3 (FIPS 180-4, FIPS 202). HMAC-SHA1 is not broken; RFC 9155 leaves it in place for TLS 1.2 record protection.

Three constructions give three guarantees. A plain hash checks integrity, and anyone can recompute it. An HMAC mixes a shared secret key into the hash, so only a key holder can produce a valid tag; because both parties hold that key, either could have made it. A digital signature (a hash signed with a private key) supports non-repudiation, since only the private key holder could have produced it. Hash chaining and digital signatures are also the primitives beneath a blockchain, which NIST describes as “tamper evident and tamper resistant digital ledgers” (Yaga et al. 2018).

Tools: where the keys live

A protocol is only as trustworthy as the place its private keys are kept. The SY0-801 objective lists “Tools” without naming any, and the document’s own note says “The lists of examples provided in Bulleted format are not exhaustive lists” (CompTIA 2025), so the four devices below remain right answers in scenarios.

A Trusted Platform Module (TPM) is a per-device crypto-processor that seals keys and measures boot. Sealing binds a key to a measured state of the machine: BitLocker seals its key to PCR 7 and PCR 11, so a changed boot path forces recovery (Microsoft n.d.).

A hardware security module (HSM) is a tamper-resistant device for an organization’s high-value keys, validated under FIPS 140-3. Public certificate authorities must hold CA keys in a FIPS 140 Level 3 or Common Criteria EAL 4 device (CA/Browser Forum 2026). FIPS 140-2 certificates moved to the CMVP Historical List in September 2026 (NIST n.d.).

A key management system (KMS) is the lifecycle and policy layer above the hardware, usually HSM-backed. In envelope encryption, a data key encrypts the object and the KMS key wraps the data key (AWS n.d.), so the key that protects the data is itself stored only in encrypted form.

A secure enclave is an on-device subsystem “isolated from the main processor,” keeping keys safe even if the kernel is compromised (Apple n.d.). Basically, the four tools differ in scope: a TPM serves one machine, an HSM serves an organization, a KMS governs the keys over time, and an enclave protects keys from the operating system on the same device.

Salting and key stretching

Password storage is where hashing, salting, and cost meet. A salt is a random per-user value mixed into the hash so that identical passwords produce different digests and precomputed tables are useless. Key stretching is the textbook name for deliberately slowing a hash, by iterating it or making it memory-hungry, so that each guess costs an attacker real time. SP 800-63B-4 requires passwords to be “salted and hashed using a suitable password hashing scheme” with a salt of at least 32 bits and a cost factor (Temoshok et al. 2025); OWASP calls the same thing a work factor. Neither says “stretching,” but the mechanism is the same.

Salting and cost solve different problems, and you need both. A salt does not slow a guess. On one Apple M4 Pro core with Python’s hashlib (October 12, 2026; an illustration, not a benchmark), salted SHA-256 managed about 3.7 million guesses per second and PBKDF2-HMAC-SHA256 at 600,000 iterations about 23. OWASP’s first choice is Argon2id with at least 19 MiB of memory, two iterations, and parallelism 1 (OWASP n.d.):

$ echo -n "correct horse battery staple" | argon2 "Qx7pL2vR9sKw4mZ1" -id -t 2 -k 19456 -p 1 -l 32 -e
$argon2id$v=19$m=19456,t=2,p=1$UXg3cEwydlI5c0t3NG1aMQ$fgGAj7c11YpV9/xJthJFyGVvBZwnOFvD862DhH6xzx8

The stored string carries the parameters and salt, so the cost can rise over time without breaking existing hashes.

What you need to know for SY0-801

• TLS 1.3 means forward secrecy on every full handshake and AEAD only; TLS 1.0 and 1.1 are findings; TLS 1.2 needs ECDHE plus AEAD suites.
• Forward secrecy comes from ephemeral key exchange, so TLS_RSA_WITH_AES_256_GCM_SHA384 has none.
• Only ESP encrypts; a gateway endpoint means tunnel mode; NAT means NAT-T on UDP 4500.
• RSA-2048 is 112-bit strength; RSA-3072, P-256, and AES-128 are each 128.
• SHA-1 and MD5 fail collision resistance; HMAC-SHA1 is not broken.
• A hash checks integrity, an HMAC adds a shared secret, and a signature adds non-repudiation.
• A salt defeats precomputed tables; a cost factor slows each guess; you need both.
• Key stretching is 701-era vocabulary for the cost factor that SP 800-63B-4 and OWASP describe; expect the mechanism, not the phrase.
• “Measured boot” or “laptop disk keys” signals TPM; “CA root key” signals HSM; “rotate and audit keys” signals KMS; “keys safe from a compromised OS” signals secure enclave.
• Blockchain and open public ledger are 701-era items; their primitives, hash chaining and digital signatures, remain in 1.3.

Check yourself

These are original practice questions, not exam items.

1. A scan shows an internal web server offering only TLS 1.0, with suites such as TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA and TLS_RSA_WITH_AES_128_CBC_SHA. Nmap’s ssl-enum-ciphers grades every suite A. What should the administrator do?

• A. Nothing, because every suite earned an A grade.
• B. Remove the static RSA suites and keep TLS 1.0.
• C. Disable TLS 1.0 and 1.1, and enable TLS 1.3 plus TLS 1.2 with ECDHE and AEAD suites.
• D. Replace the server certificate with an RSA-4096 certificate.

Answer: C. RFC 8996 says TLS 1.0 and 1.1 must not be used, and Nmap’s grade ignores the protocol version. Removing static RSA suites adds forward secrecy but keeps the deprecated protocol.

2. A certificate authority must generate and protect its root private key inside a tamper-responsive device validated at FIPS 140-3 Level 3. Which tool fits best?

• A. A TPM in the CA administrator’s laptop.
• B. A hardware security module.
• C. A secure enclave in a mobile device.
• D. A key management system that stores keys in a software database.

Answer: B. An HSM is the dedicated, validated device for an organization’s high-value keys. A TPM protects keys for one machine, and a software-only KMS lacks the hardware boundary.

3. After a breach, analysts find that users who share a password have identical stored hashes, and the hashes crack quickly on GPUs. Which change addresses both problems?

• A. Hash each password with SHA-256 instead of MD5.
• B. Encrypt the password table with AES-256.
• C. Add one secret pepper to every password before hashing.
• D. Use a unique per-user salt with Argon2id at a tuned memory and time cost.

Answer: D. The salt makes identical passwords hash differently, and Argon2id’s cost makes each guess expensive. SHA-256 is fast and unsalted, encryption is reversible with the key, and a shared pepper alone leaves identical passwords with identical hashes.

This is T-34 of the Security+ 801 Countdown: one change from SY0-701 to SY0-801 every morning until the new exam launches on November 17, 2026. Tomorrow, T-33: CVSS, CVE, and Threat Intelligence Move Into New Objective 2.1. New here? Start with T-38: The Blueprint Was Reweighted and Trimmed to 27 Objectives.

References

Apple. n.d. “The Secure Enclave.” Apple Platform Security. Accessed October 12, 2026.

AWS (Amazon Web Services). n.d. “AWS KMS Cryptography Essentials.” AWS Key Management Service Developer Guide. Accessed October 12, 2026.

Barker, Elaine. 2020. Recommendation for Key Management: Part 1: General. NIST Special Publication 800-57 Part 1 Rev. 5. Gaithersburg, MD: National Institute of Standards and Technology.

Barker, Elaine, Quynh Dang, Sheila Frankel, Karen Scarfone, and Paul Wouters. 2020. Guide to IPsec VPNs. NIST Special Publication 800-77 Rev. 1. Gaithersburg, MD: National Institute of Standards and Technology.

Barker, Elaine, and Allen Roginsky. 2024. Transitioning the Use of Cryptographic Algorithms and Key Lengths. NIST Special Publication 800-131A Rev. 3, Initial Public Draft.

CA/Browser Forum. 2026. Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates. Version 2.3.1.

CompTIA. 2023. CompTIA Security+ SY0-701 Certification Exam Objectives. Version 5.0.

CompTIA. 2025. CompTIA Security+ SY0-801 V8 Certification Exam Objectives. Document Version 2.0.

Kent, Stephen, and Karen Seo. 2005. Security Architecture for the Internet Protocol. RFC 4301. Internet Engineering Task Force.

Kwiatkowski, Kris, Panos Kampanakis, Bas Westerbaan, and Douglas Stebila. 2026. Post-Quantum Traditional (PQ/T) Hybrid Key Agreement Mechanisms for TLS 1.3. RFC 10024. Internet Engineering Task Force.

Microsoft. n.d. “BitLocker Countermeasures.” Microsoft Learn. Accessed October 12, 2026.

Moody, Dustin, Ray Perlner, Andrew Regenscheid, Angela Robinson, and David Cooper. 2024. Transition to Post-Quantum Cryptography Standards. NIST IR 8547, Initial Public Draft.

Moriarty, Kathleen, and Stephen Farrell. 2021. Deprecating TLS 1.0 and TLS 1.1. RFC 8996, BCP 195. Internet Engineering Task Force.

NIST (National Institute of Standards and Technology). 2022. “NIST Transitioning Away from SHA-1 for All Applications.” Computer Security Resource Center, December 15, 2022.

NIST (National Institute of Standards and Technology). 2024. “NIST Releases First 3 Finalized Post-Quantum Encryption Standards.” August 13, 2024.

NIST (National Institute of Standards and Technology). n.d. “FIPS 140-3 Transition Effort.” Computer Security Resource Center. Accessed October 12, 2026.

Nmap Project. n.d. “ssl-enum-ciphers.” Nmap Scripting Engine Documentation. Accessed October 12, 2026.

OpenSSL Project. n.d. “SSL_CTX_set_security_level.” OpenSSL Documentation. Accessed October 12, 2026.

OWASP Foundation. n.d. “Password Storage Cheat Sheet.” OWASP Cheat Sheet Series. Accessed October 12, 2026.

Rescorla, Eric. 2018. The Transport Layer Security (TLS) Protocol Version 1.3. RFC 8446. Internet Engineering Task Force.

Sheffer, Yaron, Peter Saint-Andre, and Thomas Fossati. 2022. Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS). RFC 9325, BCP 195. Internet Engineering Task Force.

Stevens, Marc, Elie Bursztein, Pierre Karpman, Ange Albertini, and Yarik Markov. 2017. “SHAttered.” Announced February 23, 2017. Accessed October 12, 2026.

Temoshok, David, et al. 2025. Digital Identity Guidelines. NIST Special Publication 800-63B-4.

Yaga, Dylan, Peter Mell, Nik Roby, and Karen Scarfone. 2018. Blockchain Technology Overview. NIST IR 8202.