Domain 3 — Implementation: Cryptography and PKI

Week of 2026-10-13 · Download .docx

Objectives

Compare symmetric and asymmetric encryption algorithms, key sizes, and appropriate use cases.
Explain hashing, salting, perfect forward secrecy, and why MD5 is no longer secure.
Describe the PKI hierarchy including root CA, intermediate CA, CSR, and certificate lifecycle.
Distinguish CRL from OCSP and explain certificate transparency, pinning, and wildcards.
Explain TLS 1.3 improvements and digital signature mechanics.

Key terms

symmetric encryption: Same key for encrypt and decrypt — fast; AES-256 is the current standard; key distribution is the challenge.
asymmetric encryption: Public key encrypts, private key decrypts — solves key distribution; RSA and ECC are the main algorithms.
AES-256: Advanced Encryption Standard with 256-bit key — current symmetric encryption standard; computationally infeasible to brute-force.
RSA: Asymmetric algorithm using large prime factorization; 2048–4096 bit keys required for secure use.
ECC: Elliptic Curve Cryptography — asymmetric algorithm providing equivalent security to RSA with significantly smaller keys.
hashing: One-way function producing a fixed-length digest — cannot be reversed; used for integrity and password storage.
SHA-256: Secure Hash Algorithm producing a 256-bit (32-byte) output regardless of input size.
salt: Random value added to a password before hashing — defeats rainbow table attacks by making identical passwords hash differently.
perfect forward secrecy: Ephemeral session keys so compromising the long-term key cannot decrypt past sessions.
CA: Certificate Authority — trusted entity that issues, signs, and revokes digital certificates.
CSR: Certificate Signing Request — submitted to a CA; contains the requester's public key and identity info.
OCSP: Online Certificate Status Protocol — real-time certificate revocation status check; preferred over CRL.
chain of trust: Certificate validation path from end-entity → intermediate CA → trusted root CA.
TLS 1.3: Current TLS version — 1-RTT handshake, removed weak ciphers, mandated PFS; significant security and performance improvement over 1.2.

The concept

SYMMETRIC VS. ASYMMETRIC ENCRYPTION

Cryptography protects data confidentiality, integrity, and authenticity. Symmetric encryption uses one shared key for both encrypt and decrypt — it is fast and efficient for bulk data. AES-256 (Advanced Encryption Standard, 256-bit key) is the current gold standard; its 2^256 key space makes brute-force computationally infeasible. The challenge with symmetric encryption is key distribution: how do two parties securely exchange the shared key? Asymmetric encryption solves this by using a key pair: a public key (shared openly) for encryption and a private key (kept secret) for decryption. RSA bases its security on the difficulty of factoring the product of two large primes. ECC (Elliptic Curve Cryptography) achieves equivalent security with much smaller keys — a 256-bit ECC key equals roughly a 3072-bit RSA key — making ECC preferred for TLS, mobile, and IoT.

HASHING AND PASSWORD PROTECTION

Hashing is a one-way function that converts input of any size into a fixed-length digest. SHA-256 always produces 256 bits (32 bytes) regardless of input size. Hashing is used for integrity verification (comparing file hashes) and password storage. When a user logs in, the server hashes the supplied password and compares it to the stored hash — the plaintext password is never stored. MD5 is broken: collision attacks allow two different inputs to produce the same hash, enabling attackers to substitute malicious files. Use SHA-256 or SHA-3 for all security-sensitive hashing. Salting adds a random per-user value before hashing — identical passwords produce different hashes, defeating rainbow tables (precomputed hash lookup tables). Perfect forward secrecy uses ephemeral Diffie-Hellman key exchange for each session; even if the long-term private key is later stolen, past sessions cannot be decrypted because their keys were discarded.

PKI AND CERTIFICATE MANAGEMENT

Public Key Infrastructure (PKI) manages the creation, distribution, and revocation of digital certificates. A Certificate Authority (CA) verifies the requester's identity and signs the certificate — binding a public key to an identity. The PKI hierarchy has three levels: the root CA (kept offline — compromise breaks all trust), intermediate CAs (handle day-to-day issuance), and end-entity certificates (the ones websites and users actually use). The chain of trust: a browser validates a server certificate by verifying the signature chain up through intermediate CAs to a trusted root CA in its trust store. A Certificate Signing Request (CSR) contains the requester's public key and identity information — the private key never leaves the requester. Once issued, certificates can be revoked: CRLs are periodic downloaded lists of revoked certificates; OCSP provides real-time status checks, making it preferred over CRL.

DIGITAL SIGNATURES AND TLS 1.3

A digital signature proves both authenticity (who sent it) and integrity (it was not altered). The sender computes a hash of the message and encrypts it with their private key — this is the signature. The recipient decrypts the signature with the sender's public key, recomputes the hash, and compares: if they match, authenticity and integrity are confirmed. TLS 1.3 improved over TLS 1.2 by reducing the handshake to one round-trip (1-RTT), removing weak cipher suites (RSA key exchange, RC4, 3DES, SHA-1), and mandating perfect forward secrecy via ephemeral Diffie-Hellman on every connection. Certificate transparency logs all issued certificates in public append-only logs — allowing domain owners to detect unauthorized certificate issuance by compromised or rogue CAs.

Standards alignment: CompTIA Security+ SY0-701 Domain 3.1 (Implementation — Cryptography and PKI); Maryland Blueprint College and Career Readiness — Technology and Engineering.

Worked examples

Example 1: A developer needs to: (a) encrypt a 500 GB database backup, (b) exchange the encryption key with a remote site, and (c) store user passwords. She selects AES-256 for the backup (symmetric — fast for bulk data). For the key exchange, she uses RSA or ECDH asymmetric exchange (asymmetric — solves the key distribution problem without a pre-shared secret). For password storage, she uses bcrypt (a salted hashing function) rather than SHA-256 alone — bcrypt adds salting and artificial slowness to defeat offline brute-force attacks. Each decision matches the cryptographic tool to the specific security requirement.

Example 2: A company discovers that an intermediate CA private key was stolen by an insider. The incident response team immediately revokes all certificates issued by that intermediate CA and publishes the revocation via OCSP. Browsers checking OCSP receive a 'revoked' status and display an error to users. The root CA is offline and unaffected. A new intermediate CA is created from the root CA, and new certificates are issued for all affected domains within 4 hours. Because TLS 1.3 mandates perfect forward secrecy, past TLS sessions encrypted with those certificates cannot be decrypted even with the stolen key.

Common mistakes

Confusing hashing (one-way, for integrity/passwords) with encryption (reversible, for confidentiality) — you cannot 'decrypt' a hash.
Assuming MD5 is acceptable for file integrity checks in security contexts — MD5 collision attacks make it unsuitable; use SHA-256.
Forgetting that salting defeats rainbow tables but not brute-force against a specific hash — use a slow hashing algorithm (bcrypt, Argon2) for passwords.
Confusing CRL (periodic downloaded list, can be stale) with OCSP (real-time query, preferred) — OCSP provides fresher revocation status.
Thinking a self-signed certificate provides no encryption — it provides the same encryption as a CA-issued certificate; the difference is identity validation, not encryption strength.

Self-check

Try each question before reading the answer. Answers at the bottom of this page.

1. Which type of encryption uses the same key for both encrypt and decrypt?

Asymmetric (RSA, ECC)
Hashing (SHA-256)
Symmetric (AES-256)
Key exchange (ECDH)

2. Salting a password before hashing prevents:

Brute-force attacks entirely
Chosen-plaintext attacks
Rainbow table attacks
Collision attacks

3. Why is ECC preferred over RSA for mobile and IoT?

ECC requires larger keys
ECC provides equivalent security with much smaller keys
ECC is a symmetric algorithm
ECC requires no key exchange

4. A digital signature proves:

That data was encrypted in transit
Only that the certificate is valid
Authenticity (who sent it) and integrity (not altered)
That the sender's public key is correct

5. TLS 1.3 improved over TLS 1.2 by:

Adding RSA key exchange support
Removing session resumption
Requiring only 1-RTT handshake, removing weak ciphers, and mandating PFS
Adding MD5 as a hash option

Self-check answers

1. C — Symmetric encryption uses one shared key for both operations — fast for bulk data. AES-256 is the current standard.
2. C — Salt makes each password's hash unique even when two users choose the same password — precomputed rainbow tables become useless.
3. B — A 256-bit ECC key equals roughly a 3072-bit RSA key in security — smaller keys mean faster computation and lower bandwidth.
4. C — The sender encrypts a message hash with their private key. The recipient decrypts with the sender's public key and compares hashes — both authenticity and integrity are confirmed.
5. C — TLS 1.3 is faster (1-RTT) and more secure (removed RC4, 3DES, RSA key exchange; PFS mandatory on every connection).

Canvas is the official record. This companion enhances the PGCC curriculum; it does not replace it. Last name and class year only. Students with a 504 plan or IEP: your accommodations apply.

↑ Back to top