Cryptography is one of the highest-weighted domains on the Security+ exam. Questions test whether you can match an algorithm to its purpose, identify what a given scenario requires, and distinguish between concepts that sound similar but work differently.
Hashing: Integrity, One-Way
A hash function takes input data of any size and produces a fixed-length output (the hash or digest). Hashing is one-way — you cannot reverse a hash to recover the original data.
Hashing provides integrity, not confidentiality. If a file's hash changes, the file has been modified.
Common hash algorithms:
- MD5 — 128-bit digest. Considered cryptographically broken (collision vulnerabilities). Still used for non-security purposes like file integrity checks.
- SHA-1 — 160-bit digest. Also deprecated for security use.
- SHA-256 — Part of the SHA-2 family. 256-bit digest. Currently strong and widely used.
- SHA-3 — Newer standard, different internal design from SHA-2.
Exam trap: a question asks which algorithm provides the strongest hashing. SHA-3 and SHA-256 are both acceptable answers, but SHA-256 appears more frequently on current Security+ objectives. MD5 and SHA-1 are explicitly weak.
Symmetric Encryption: Speed, Bulk Data
Symmetric encryption uses the same key for both encryption and decryption. It is fast and efficient, making it suitable for encrypting large amounts of data.
Common symmetric algorithms:
- AES — Advanced Encryption Standard. Block cipher. Key sizes: 128, 192, or 256 bits. The current gold standard for symmetric encryption.
- 3DES (Triple DES) — Applies DES three times. Being phased out.
- DES — Data Encryption Standard. 56-bit key. Considered broken. Do not recommend.
- RC4 — Stream cipher. Used in WEP and early TLS. Now deprecated.
The weakness of symmetric encryption: both parties need the same key, and distributing that key securely is the hard part. This is solved by asymmetric encryption.
Asymmetric Encryption: Key Exchange, Authentication
Asymmetric encryption uses a key pair: a public key and a private key. Data encrypted with the public key can only be decrypted with the private key, and vice versa.
- Encryption — Use the recipient's public key to encrypt. Only the recipient's private key decrypts it.
- Digital signature — Use the sender's private key to sign. Anyone with the sender's public key can verify the signature.
Common asymmetric algorithms:
- RSA — Based on the difficulty of factoring large numbers. Key sizes typically 2048 or 4096 bits.
- ECC (Elliptic Curve Cryptography) — Provides equivalent security to RSA with smaller key sizes. Preferred for mobile and IoT.
- Diffie-Hellman — Used for key exchange, not encryption or signing directly.
Digital Signatures: Authentication and Non-Repudiation
A digital signature proves who sent a message and that the message was not altered. The process:
- Sender hashes the message
- Sender encrypts the hash with their private key (this is the signature)
- Recipient decrypts the signature with the sender's public key
- Recipient hashes the received message and compares with the decrypted hash
- If they match, the message is authentic and unaltered
Exam trap: candidates mix up which key is used. The private key signs (only the owner can sign). The public key verifies (anyone can verify). Encrypting data for confidentiality is different: the recipient's public key encrypts, and the recipient's private key decrypts.
Hybrid Encryption
TLS and most practical systems use hybrid encryption: asymmetric encryption to securely exchange a symmetric key, then symmetric encryption (AES) for the bulk data transfer. This combines the security of asymmetric key exchange with the speed of symmetric encryption.
Certificate Authorities and PKI
A Certificate Authority (CA) issues digital certificates that bind a public key to an identity. When you visit an HTTPS website, the server presents a certificate signed by a CA your browser trusts. This confirms the server's public key is genuine.
Exam scenarios: "Which component verifies the identity of a web server?" — Certificate signed by a trusted CA. "What provides non-repudiation for a signed document?" — Digital signature using the sender's private key.
Quick Reference
| Goal | Algorithm Type | Example |
|---|---|---|
| Integrity check | Hash | SHA-256, MD5 |
| Confidentiality (fast) | Symmetric | AES |
| Key exchange | Asymmetric | RSA, ECC, DH |
| Authentication + integrity | Digital signature | RSA + SHA-256 |
| Both confidentiality and authentication | Hybrid | TLS |
Practice Security+ cryptography questions until you can match each algorithm to its purpose without hesitation.
Symmetric Algorithm Comparison
Knowing the algorithm name is not enough — the exam expects you to know the key sizes, cipher type, and status of each.
| Algorithm | Type | Key Sizes | Status | Notes |
|---|---|---|---|---|
| AES | Block cipher | 128, 192, 256 bit | Current standard | Used in TLS, WPA2/3, disk encryption |
| 3DES | Block cipher | 112 effective bits | Legacy, deprecated | Applies DES three times; too slow for modern use |
| DES | Block cipher | 56-bit | Broken | Crackable in hours; never recommend |
| ChaCha20 | Stream cipher | 256-bit | Current | Used in TLS 1.3, preferred for mobile and IoT |
| RC4 | Stream cipher | Variable | Deprecated | Used in WEP and old TLS; multiple vulnerabilities |
What trips people up: ChaCha20 is stream cipher, AES is block cipher — they get tested together because both are "current." ChaCha20 is preferred in environments where hardware AES acceleration is not available (mobile processors, IoT). AES is the default for everything else.
RC4 specifically: RC4's stream cipher design produces a keystream that has statistical biases. Those biases led to WEP being cracked trivially and to TLS using RC4 being broken in BEAST and POODLE attacks. The exam treats RC4 as unambiguously deprecated.
Block cipher operating modes: The exam cares about ECB vs CBC (covered in the pitfalls section below). AES is the algorithm; the mode (ECB, CBC, GCM, CTR) is separate. AES-GCM is the mode used in modern TLS because it provides both confidentiality and integrity in one pass.
RSA Key Length — Why 2048 Minimum Matters
RSA security depends on the difficulty of factoring the product of two large prime numbers. Key length determines how large those primes are.
The numbers the exam tests: RSA-1024 is no longer considered secure — the computing power required to factor 1024-bit numbers has come within reach. RSA-2048 is the current minimum for security. RSA-4096 is used for very long-lived certificates (root CAs) where the cost of compromise would be catastrophic.
For comparison: AES-128 is considered equivalent in security strength to RSA-3072. If someone asks you to compare RSA and AES key sizes, they are not equivalent — a 128-bit AES key provides roughly the same security as a 3072-bit RSA key because they rely on fundamentally different mathematical problems.
The exam scenario: "An administrator needs to generate a key pair for a TLS certificate. What is the minimum recommended RSA key length?" The answer is 2048. If the question says "long-term high-value certificate," the answer is 4096.
Certificate Chain of Trust — Reading a Real Certificate
When your browser connects to https://example.com, it receives a certificate. That certificate contains a chain that leads back to a root CA your browser already trusts. Here is how that chain works.
Root CA: A certificate authority that is inherently trusted — your browser, operating system, or device comes pre-installed with a list of root CA certificates. Root CAs are offline as much as possible because compromising one would invalidate trust for everything it signed.
Intermediate CA: The root CA signs an intermediate CA's certificate. The intermediate CA is the one that actually issues certificates to websites. This protects the root — if an intermediate is compromised, only certificates it issued are affected; the root is still intact.
Leaf certificate (end-entity certificate): This is the certificate your browser receives from the website. It is signed by an intermediate CA. Your browser verifies the signature using the intermediate's public key, then verifies the intermediate's certificate using the root's public key.
The exam tests: "Which entity issues the certificate for a website that uses HTTPS?" The answer is the intermediate CA (or the CA in general, not the root CA directly). "What happens if the intermediate CA's private key is compromised?" All certificates issued by that intermediate must be revoked and reissued; the root CA is unaffected.
Certificate revocation: CRL (Certificate Revocation List) is a downloadable list of revoked certificates. OCSP (Online Certificate Status Protocol) allows real-time revocation checking. OCSP is newer and more efficient. OCSP stapling has the server pre-fetch its own OCSP response and include it in the TLS handshake, reducing latency.
Common Crypto Pitfalls the Exam Tests
ECB mode vs CBC mode. ECB (Electronic Codebook) encrypts each block of plaintext independently with the same key. This means identical plaintext blocks produce identical ciphertext blocks. An attacker can see the structure of the data even without decrypting it — the famous Linux Tux penguin image encrypted with ECB still shows the penguin shape. CBC (Cipher Block Chaining) XORs each plaintext block with the previous ciphertext block before encrypting, so identical plaintext blocks produce different ciphertext. CBC is the minimum acceptable mode. The exam frames this as: ECB is weak because it reveals patterns.
Salting passwords. A hash of a common password like "password123" is always the same. Attackers precompute a dictionary of common passwords and their hashes — this is a rainbow table. A salt is a random value added to the password before hashing, making each hash unique even for identical passwords. hash("password123" + "randomsalt42") produces a different output than hash("password123" + "differentsalt"). The salt is stored alongside the hash. Rainbow tables become useless because you would need a separate table for every possible salt.
Key escrow. A copy of encryption keys is deposited with a trusted third party (the escrow agent). This allows recovery of encrypted data if the key holder is unavailable. The controversy: governments have pushed for mandatory key escrow so law enforcement can decrypt data with a court order. The security risk: if the escrow system is compromised, all escrowed keys are exposed.
Forward secrecy (perfect forward secrecy, PFS). If an attacker records encrypted traffic today and later compromises the server's private key, they could retroactively decrypt all that traffic — unless the session used ephemeral keys. With forward secrecy, each session generates a new temporary key pair for key exchange. The session key is never stored. Compromising the server's long-term key later does not help decrypt past sessions. TLS 1.3 mandates PFS. The cipher suites that provide PFS use ECDHE (Elliptic Curve Diffie-Hellman Ephemeral) for key exchange.
PGP and S/MIME — Email Encryption Standards
Both are on the SY0-701 objectives for email security.
PGP (Pretty Good Privacy): Uses a web of trust model — individuals sign each other's keys to establish trust, rather than relying on a centralised CA. If Alice trusts Bob's key and Bob has signed Carol's key, Alice can extend some trust to Carol. PGP is used heavily in open source communities and for secure email between individuals.
S/MIME (Secure/Multipurpose Internet Mail Extensions): Uses the standard PKI model with certificates issued by a CA. More common in enterprise environments where email signing and encryption is deployed centrally. S/MIME provides email signing (authenticity and non-repudiation) and encryption (confidentiality). The recipient needs the sender's public key certificate to verify a signature.
Exam distinction: PGP = web of trust, decentralised. S/MIME = PKI, CA-based, enterprise. Both provide email encryption and signing. When the question describes an enterprise deploying signed email company-wide using existing certificate infrastructure, the answer is S/MIME.