Lesson 2 of 12 — Cryptography & PKI
Symmetric and asymmetric encryption, hashing algorithms, digital signatures, certificate authorities, the PKI lifecycle, and real-world TLS certificate analysis — the mathematical backbone of modern security.
Every time you visit an HTTPS website, send a digitally signed email, or log into a corporate VPN, cryptography is working silently in the background. It is the mathematical engine that makes trustworthy digital communication possible — and it accounts for significant question coverage across every Security+ domain, not just General Concepts. Understanding cryptography is not optional for a security professional; it is a prerequisite.
This lesson demystifies the core cryptographic building blocks: how symmetric encryption provides fast, bulk data protection; how asymmetric encryption solves the key distribution problem; how hashing proves data integrity without revealing the data; and how all three come together in the PKI ecosystem to create the digital certificates that power secure web browsing, code signing, and email encryption. By the end of today, you will be able to read an actual TLS certificate and understand exactly what every field is telling you — and why an attacker cares about it.
Symmetric vs. asymmetric encryption algorithms, key types, use cases, and one-way hash functions that prove integrity.
Symmetric (AES, 3DES) uses one shared key — fast but requires secure key exchange. Asymmetric (RSA, ECC) uses a public/private key pair — solves distribution but is computationally slow. Hashing (SHA-256, MD5) is a one-way function for integrity verification.
How private keys produce signatures that prove identity and integrity — and what an X.509 certificate actually contains.
A digital signature is a hash of a message, encrypted with the sender's private key. X.509 certificates bind a public key to an identity, signed by a trusted CA. Certificates enable TLS, code signing, email encryption (S/MIME), and client authentication.
The end-to-end certificate lifecycle — from key generation and CA signing to renewal and revocation — plus live TLS certificate analysis.
The PKI lifecycle: generate key pair → create CSR → CA validates → CA issues signed certificate → deploy → monitor expiry → renew or revoke via CRL / OCSP. Real TLS certificates expose the Subject, Issuer, SAN, validity window, algorithm, and public key details.
Symmetric algorithms, asymmetric key pairs, hash functions, and obfuscation
Cryptography rests on two primary operations: encryption (a reversible transformation requiring a key) and hashing (a one-way transformation producing a fixed-length digest). Security+ tests both the theoretical properties of these operations and your ability to select the right tool for a given scenario.
| Property | Symmetric Encryption | Asymmetric Encryption |
|---|---|---|
| Keys Used | Single shared secret key for encrypt & decrypt | Public key encrypts; private key decrypts (or vice versa for signatures) |
| Speed | Very fast — suited for bulk data encryption | Computationally slow — not used for large data volumes |
| Key Problem | Secure key distribution is the fundamental challenge | Solves key distribution — public key can be shared freely |
| Key Algorithms | AES (128/256-bit), 3DES, ChaCha20 | RSA (2048/4096-bit), ECC (P-256, P-384), Diffie-Hellman |
| Key Length | 128–256 bits is standard; shorter keys are weaker | 2048-bit RSA ≈ 112-bit symmetric security level |
| Use Cases | Encrypting files, database fields, full-disk encryption, VPN tunnel data | TLS key exchange, digital signatures, certificate issuance, SSH keys |
| Common Hybrid Use | TLS uses asymmetric to exchange a symmetric session key — combining security of asymmetric with speed of symmetric | |
The gold standard for symmetric encryption, adopted by NIST in 2001. AES operates on 128-bit blocks and supports 128-, 192-, or 256-bit key lengths. AES-256 is considered computationally unbreakable with current technology and is used by U.S. government agencies to protect classified information.
RSA (Rivest–Shamir–Adleman) is the most widely deployed asymmetric algorithm, used in TLS certificates, SSH, and PGP. Its security depends on the computational difficulty of factoring large prime numbers. ECC (Elliptic Curve Cryptography) achieves equivalent security at much shorter key lengths.
A hash function takes any input and produces a fixed-length output (digest) that uniquely represents the input. Hash functions are one-way — you cannot reverse a hash to get the original data. They are deterministic — the same input always produces the same digest.
Obfuscation makes data or code harder to understand without actually encrypting it. Common examples include Base64 encoding, ROT13, and code minification. These are not encryption because they do not require a key and can be reversed without one.
How asymmetric cryptography enables authentication, integrity, and non-repudiation
A digital signature is not a scanned image of a handwritten signature — it is a cryptographic proof of identity and message integrity. Digital certificates are the mechanism by which public keys are bound to real-world identities and made trustworthy.
Signing (sender side):
Verification (recipient side):
The Subject field identifies the entity the certificate was issued to (e.g., Common Name = www.example.com, Organization = Example Corp). The SAN (Subject Alternative Name) lists all additional domain names and IP addresses the certificate is valid for — modern browsers only trust the SAN, not the CN.
The Issuer field identifies the CA that signed the certificate (e.g., DigiCert Global Root G2). The CA's digital signature over the certificate contents is what makes the certificate trustworthy — any tampering invalidates the signature.
The Not Before / Not After fields define the certificate's active window. Expired certificates trigger browser warnings. Since September 2020, publicly trusted TLS certificates are capped at 398-day validity to reduce long-term exposure from compromised keys.
The certificate embeds the subject's public key and specifies the key algorithm (RSA 2048, ECDSA P-256, etc.). Browsers use this public key to establish the TLS session. The signature algorithm field specifies how the CA signed the certificate (e.g., sha256WithRSAEncryption).
A unique identifier assigned by the CA to each certificate it issues. The serial number is used in Certificate Revocation Lists (CRLs) and OCSP (Online Certificate Status Protocol) responses to identify revoked certificates.
Extensions encode additional policy information: Key Usage restricts what the key may be used for (e.g., digital signature, key encipherment). Extended Key Usage specifies application purposes (TLS server authentication, code signing, email protection). Basic Constraints indicates whether the certificate is a CA certificate.
From key generation to revocation — and how to read a real certificate
PKI is not a single product — it is an ecosystem of roles, processes, and policies that govern the complete lifecycle of digital certificates. Understanding this lifecycle is essential for Security+ because both mismanagement (expired certs, weak keys, improper revocation) and deliberate attacks target every phase.
The entity (server, user, or device) generates an asymmetric key pair. The private key is created and stored securely — ideally in a Hardware Security Module (HSM) or a TPM (Trusted Platform Module) to prevent extraction. The private key must never leave the HSM in plaintext. Key length matters: RSA 2048-bit minimum; RSA 4096 or ECDSA P-256 preferred for new deployments.
The entity creates a CSR — a structured message containing the public key and identity information (subject, organization, domain). The CSR is signed with the entity's private key to prove possession of it. The CSR is submitted to the CA; it contains no secrets and can be transmitted over insecure channels.
The CA performs identity validation — the rigor depends on the certificate type. Domain Validation (DV) only confirms domain control (automated, minutes). Organization Validation (OV) verifies organizational identity (hours to days). Extended Validation (EV) performs thorough legal entity verification (days to weeks). The CA then signs the certificate with its private key and returns it to the requester.
The signed certificate is installed on the server (or device). For web servers, the full certificate chain (leaf + intermediate(s)) must be configured — a missing intermediate is one of the most common TLS configuration errors. Certificates can also be published to LDAP directories for S/MIME email encryption lookup.
Certificate expiry monitoring is a critical operational task — expired certificates cause outages (systems refuse connections) and security alerts. Certificates should be renewed 30–60 days before expiration. Let's Encrypt's ACME protocol automates this process for public websites. Enterprises use certificate lifecycle management (CLM) tools to track their entire certificate inventory.
When a certificate is compromised, mis-issued, or the entity's status changes, it must be revoked before expiration. CRL (Certificate Revocation List): A periodically published list of revoked serial numbers — can be large and stale. OCSP (Online Certificate Status Protocol): Real-time single-certificate status check — more efficient but requires server availability. OCSP Stapling: The server pre-fetches its own OCSP response and staples it to the TLS handshake, improving privacy and performance.
Sort each algorithm or technique into the correct cryptographic category
Read the sample certificate data, then answer questions about what each field reveals
api.example-corp.com. Based on the certificate, will the TLS connection succeed without a certificate warning?Select the best answer for each question, then submit for graded feedback