Explain the importance of using appropriate cryptographic solutions
Cryptography is the backbone of confidentiality, integrity, authentication, and non-repudiation. The exam expects you to know when to use each type, not how to implement the math.
Symmetric Encryption
One key encrypts and decrypts. Both parties must share the same secret key.
Algorithms:
- AES (Advanced Encryption Standard) — The standard. 128, 192, or 256-bit keys. AES-256 is the gold standard for data at rest.
- 3DES (Triple DES) — Legacy. Applies DES three times. Being phased out — slower and weaker than AES.
- ChaCha20 — Stream cipher alternative to AES. Used in TLS 1.3 and WireGuard. Performs well on devices without AES hardware acceleration.
Strengths: Fast, efficient for bulk data encryption. Weakness: Key distribution problem — how do you securely share the key? This is what asymmetric crypto solves.
Use cases: Disk encryption (BitLocker, LUKS), database encryption, VPN tunnels, TLS session encryption (after key exchange).
Asymmetric Encryption
Two mathematically related keys: public key (shared openly) and private key (kept secret).
- Encrypt with public key → only private key can decrypt (confidentiality)
- Sign with private key → anyone with public key can verify (authentication, non-repudiation)
Algorithms:
- RSA — Most widely deployed. Key sizes: 2048-bit minimum, 4096-bit recommended. Used for key exchange and digital signatures.
- ECC (Elliptic Curve Cryptography) — Shorter keys for equivalent strength (256-bit ECC ≈ 3072-bit RSA). Preferred for mobile/IoT where compute is limited.
- Diffie-Hellman (DH) — Key exchange protocol, not encryption. Allows two parties to establish a shared secret over an insecure channel. ECDHE (Elliptic Curve Diffie-Hellman Ephemeral) is the modern variant used in TLS.
Strengths: Solves the key distribution problem. Enables digital signatures. Weakness: Slow — never used for bulk data. Used to exchange symmetric keys, which then do the heavy lifting.
Hashing
One-way function that produces a fixed-length digest from any input. Cannot be reversed.
Algorithms:
- SHA-256 (SHA-2 family) — Current standard. 256-bit digest. Used in certificates, integrity verification, blockchain.
- SHA-3 — Alternative to SHA-2, different internal design. Not a replacement — a backup if SHA-2 is ever broken.
- MD5 — Broken. Collision attacks are trivial. Never use for security — only for non-security checksums.
- SHA-1 — Deprecated. Collision demonstrated in 2017. Legacy systems still use it but it’s not acceptable for new deployments.
Use cases:
- File integrity verification (compare hash before and after transfer)
- Password storage (hash + salt, never plaintext)
- Digital signatures (sign the hash, not the full document)
Key Concepts
- Collision: Two different inputs producing the same hash. Fatal for a hash algorithm’s security.
- Salt: Random value added to input before hashing. Prevents rainbow table attacks on password hashes. Each password gets a unique salt.
- Key stretching: Deliberately slow hashing (PBKDF2, bcrypt, Argon2) to make brute-force attacks expensive.
Digital Signatures
Combine hashing and asymmetric encryption to prove integrity and authenticity:
- Sender hashes the message
- Sender encrypts the hash with their private key (this is the signature)
- Recipient decrypts the signature with sender’s public key
- Recipient independently hashes the message and compares
If hashes match: message is authentic (came from the signer) and has integrity (wasn’t modified).
PKI (Public Key Infrastructure)
The trust system that makes asymmetric crypto work at scale.
Certificate Authority (CA) — Trusted entity that issues digital certificates. Vouches for the binding between a public key and an identity.
Certificate chain:
- Root CA (self-signed, offline, highly protected)
- Intermediate CA (signs end-entity certs, protects root)
- End-entity cert (your server’s cert)
Certificate types:
- DV (Domain Validation) — CA verified domain ownership. Quick, cheap.
- OV (Organization Validation) — CA verified the organization exists. More trust.
- EV (Extended Validation) — Thorough vetting. Used for high-trust sites.
- Wildcard — Covers
*.domain.com. Convenient but single point of failure if compromised. - SAN (Subject Alternative Name) — Single cert for multiple specific domains.
- Self-signed — Not issued by a CA. Used internally (lab environments, testing). Browsers don’t trust them.
Certificate lifecycle:
- Issuance → Usage → Renewal → Revocation
- CRL (Certificate Revocation List) — Published list of revoked certs. Can be stale.
- OCSP (Online Certificate Status Protocol) — Real-time revocation checking. Faster than CRL.
- OCSP Stapling — Server fetches its own OCSP response and presents it during TLS handshake. Reduces latency, improves privacy.
Block Cipher Modes
How a block cipher processes data beyond a single block. CompTIA tests these — know the differences and when each is appropriate.
| Mode | How It Works | Strengths | Weaknesses |
|---|---|---|---|
| ECB (Electronic Codebook) | Each block encrypted independently with same key | Simple, parallelizable | Insecure — identical plaintext blocks produce identical ciphertext. Patterns preserved. Never use for real data. |
| CBC (Cipher Block Chaining) | Each block XORed with previous ciphertext block before encryption. Uses IV. | Hides patterns. Widely used. | Sequential (can’t parallelize encryption). Padding oracle attacks if implemented poorly. |
| CTR (Counter) | Encrypts a counter value, XORs result with plaintext. Turns block cipher into stream cipher. | Parallelizable, no padding needed. | Nonce reuse is catastrophic — reveals plaintext. |
| GCM (Galois/Counter Mode) | CTR mode + authentication tag. Provides both encryption and integrity. | AEAD — authenticated encryption. Fast, parallelizable, tamper-evident. | Nonce reuse catastrophic (same as CTR). |
AEAD (Authenticated Encryption with Associated Data): Encryption that provides confidentiality AND integrity/authenticity in one operation. GCM is the primary example. This is what TLS 1.3 requires.
Exam tip: If a question asks about encrypting data where you also need to verify it wasn’t tampered with, the answer is GCM (or any AEAD mode). If the question shows identical ciphertext blocks, the answer is “ECB is being used and that’s the problem.”
Perfect Forward Secrecy (PFS)
PFS ensures that compromising a long-term key doesn’t compromise past session keys.
How It Works
- Without PFS: Server uses its long-term RSA key for key exchange. If that key is later stolen, an attacker who captured encrypted traffic can retroactively decrypt all of it.
- With PFS: Each session uses ephemeral (temporary) Diffie-Hellman keys for key exchange. Session keys are generated, used, and discarded. Even if the server’s long-term key is compromised, past sessions remain encrypted.
Ephemeral vs. Non-Ephemeral
| Key Exchange | Ephemeral? | Forward Secrecy? |
|---|---|---|
| RSA key exchange | No | No — same key decrypts all sessions |
| DHE (Diffie-Hellman Ephemeral) | Yes | Yes — new key per session |
| ECDHE (Elliptic Curve DHE) | Yes | Yes — new key per session, more efficient |
| Static DH | No | No — reused DH parameters |
TLS 1.3 mandates PFS. Only ECDHE and DHE are allowed for key exchange — RSA key exchange was removed entirely. This is one of the major security improvements over TLS 1.2.
Certificate Formats
CompTIA tests these. Know the format, encoding, and what’s inside.
| Format | Encoding | Contains | Common Use |
|---|---|---|---|
| PEM (.pem, .crt, .cer) | Base64 (text) | Cert, key, or chain. Starts with -----BEGIN CERTIFICATE----- | Linux/Apache/Nginx. Most common format. |
| DER (.der, .cer) | Binary | Single certificate | Java, Windows. Binary version of PEM. |
| PFX/PKCS#12 (.pfx, .p12) | Binary | Certificate + private key + chain (bundled, password-protected) | Windows/IIS. Exporting certs with keys. |
| P7B/PKCS#7 (.p7b, .p7c) | Base64 or Binary | Certificates and chain only (no private key) | Windows, Java. Certificate chain distribution. |
Exam tip: If the question involves exporting a certificate WITH its private key, the answer is PFX/PKCS#12. If it’s just the certificate chain without the key, it’s P7B.
Certificate Pinning and Transparency
Certificate Pinning
- Application hardcodes or remembers which certificate (or public key) belongs to a specific server
- Prevents MITM attacks using fraudulently issued certificates — even if an attacker gets a valid cert from a compromised CA, the pin won’t match
- HPKP (HTTP Public Key Pinning) was the web standard but is now deprecated — too easy to brick your site if you lose the pinned key
- Still used in mobile apps (custom trust stores) and internal applications
Certificate Transparency (CT)
- Public, append-only logs of all certificates issued by participating CAs
- Allows domain owners to monitor for unauthorized certificate issuance
- How it works: CAs submit certificates to CT logs → monitors watch for unexpected certs → domain owner gets alerted if someone issues a cert for their domain without authorization
- Google Chrome requires CT compliance for all publicly trusted certificates
- This is what powers
crt.sh— the tool we use for subdomain enumeration in ASM
Certificate Lifecycle Operations
| Operation | What Changes | When |
|---|---|---|
| Renewal | Extends expiration date. Same key, same identity info. | Before expiration. Routine maintenance. |
| Rekeying | New key pair generated. Same identity info. New cert issued. | Key compromise suspected, or key rotation policy. |
| Reissuance | New certificate with potentially different attributes (new domain, new org info). New key optional. | Domain change, org name change, CA migration. |
| Revocation | Certificate invalidated before expiration. Published to CRL / OCSP. | Key compromise confirmed, employee departure, domain loss. |
Key Derivation
Expanding on key stretching from the hashing section — CompTIA may test the comparison:
| Algorithm | Approach | Strength | Weakness |
|---|---|---|---|
| PBKDF2 | Iterated HMAC-SHA. Configurable iterations. | NIST approved. Widely supported. | GPU-friendly (attackers can parallelize). |
| bcrypt | Blowfish-based. Cost factor parameter. | Memory-hard (harder to parallelize on GPU). Mature. | Fixed 72-byte input limit. |
| Argon2 | Memory-hard + CPU-hard. Configurable memory, time, parallelism. | Best current option. Won Password Hashing Competition. Resistant to GPU/ASIC attacks. | Newer, less universal support. |
Decision logic: If the question asks for the most secure password hashing, Argon2 > bcrypt > PBKDF2. If it asks what’s NIST-approved, PBKDF2 (though Argon2 is gaining acceptance).
Key Management
The hardest part of crypto isn’t the algorithm — it’s managing the keys.
- Key generation: Use cryptographically secure random number generators. Never reuse keys across systems.
- Key storage: HSMs (Hardware Security Modules), TPMs, key vaults. Never in plaintext config files.
- Key rotation: Regular replacement of keys. Limits the window of exposure if a key is compromised.
- Key escrow: Third party holds a copy of the key. Controversial — creates a trust dependency.
- Key destruction: Crypto-shred: destroy the key and the encrypted data becomes unrecoverable. Used for secure data disposal.
Cryptographic Use Cases
| Need | Solution |
|---|---|
| Data at rest | AES-256 (symmetric) |
| Data in transit | TLS 1.3 (ECDHE for key exchange, AES/ChaCha20 for encryption) |
| Email signing | S/MIME or PGP (asymmetric + hashing) |
| File integrity | SHA-256 hash comparison |
| Password storage | bcrypt/Argon2 (salted + stretched hash) |
| VPN | IPSec (IKE for key exchange, ESP for encryption) or WireGuard (ChaCha20) |
| Code signing | RSA/ECC digital signature on hash of binary |
| Disk encryption | AES-256 via BitLocker (Windows), LUKS (Linux), FileVault (macOS) |
Cryptographic Decision Logic
Algorithm Selection
| If the scenario says… | Choose… | Because… |
|---|---|---|
| ”Encrypt large amounts of data quickly” | AES-256 | Symmetric, fast for bulk data |
| ”Exchange keys over an insecure channel” | ECDHE / Diffie-Hellman | Key agreement without pre-shared secret |
| ”Digitally sign a document” | RSA or ECC signature | Asymmetric, provides non-repudiation |
| ”Verify file integrity” | SHA-256 | Hash comparison |
| ”Store passwords” | Argon2 or bcrypt | Salted, stretched, intentionally slow |
| ”Encrypt data in transit” | TLS 1.3 (ECDHE + AES-GCM) | Key exchange + authenticated encryption |
| ”Need encryption + integrity in one operation” | AES-GCM (AEAD) | Authenticated encryption |
| ”Low-power / IoT device” | ECC | Shorter keys, less compute than RSA |
| ”Need forward secrecy” | ECDHE | Ephemeral keys, each session unique |
”Which is MOST secure?” Cheat Sheet
| Category | Most Secure | Acceptable | Deprecated/Broken |
|---|---|---|---|
| Symmetric | AES-256 | AES-128, ChaCha20 | DES, 3DES, RC4 |
| Asymmetric | ECC-384, RSA-4096 | ECC-256, RSA-2048 | RSA-1024, DSA |
| Hashing | SHA-3, SHA-256 | SHA-512, SHA-384 | MD5, SHA-1 |
| Key exchange | ECDHE (PFS) | DHE (PFS) | Static RSA, static DH |
| Password hashing | Argon2 | bcrypt | PBKDF2 (acceptable but GPU-friendly), MD5, SHA-1 |
| Block cipher mode | GCM (AEAD) | CBC (with HMAC) | ECB (never) |
| TLS version | TLS 1.3 | TLS 1.2 | TLS 1.0, TLS 1.1, SSL (all) |
Blockchain and Steganography
Blockchain — Distributed, immutable ledger using chained hashes. Each block contains the hash of the previous block. Relevant to security for immutable audit logs and certificate transparency.
Steganography — Hiding data within other data (images, audio, video). Not encryption — the data is hidden, not scrambled. Exam questions will test whether you can distinguish steganography from encryption.
Offensive Context
Crypto fails at the implementation, not the math. Attackers don’t break AES-256 — they steal the key from a misconfigured environment variable, exploit a padding oracle, force a protocol downgrade to a weaker cipher suite, or intercept the key exchange. Understanding these attack paths is what makes your crypto deployment decisions meaningful. When the exam asks you to choose the “most secure” option, it’s testing whether you know where the real weaknesses are.