2.6 Encryption, Hashing, Certificates & PKI
Key Takeaways
- Symmetric encryption uses one shared key and is fast enough for bulk data; asymmetric encryption uses a mathematically linked key pair and solves the key-distribution problem.
- Hashing is one-way and verifies integrity; encryption is reversible with a key and provides confidentiality — the exam tests this distinction constantly.
- AES-256, RSA-2048 or larger, ECC, and SHA-256 or SHA-3 are current; DES, 3DES, RC4, MD5, and SHA-1 are deprecated and must be recognized as weak.
- Data exists in three states — in transit, at rest, and in use — and each requires a different protection mechanism, with data in use being the hardest to protect.
- A digital certificate binds a public key to a verified identity, and PKI is the hierarchy of certificate authorities, registration authorities, and revocation checks that makes that binding trustworthy.
2.6 Encryption, Hashing, Certificates & PKI
Quick Answer: Encryption is a reversible transformation that protects confidentiality — with the right key you get the original data back. Hashing is a one-way transformation that protects integrity — you can prove data has not changed, but you can never recover it from the digest. Symmetric encryption uses one shared key and is fast; asymmetric encryption uses a public/private key pair and solves the problem of distributing that shared key safely. Certificates bind a public key to a verified identity, and PKI is the trust hierarchy that makes the binding meaningful.
Blueprint sub-topic 1.4 asks you to explain encryption methods and applications. It is one of the densest items in Domain 1, and it feeds directly into Domain 2 (VPNs, secure protocols, wireless encryption) and Domain 3 (full-disk encryption, BYOD data protection). Getting the vocabulary exactly right here pays off across the whole exam.
Symmetric vs. Asymmetric Encryption
| Characteristic | Symmetric encryption | Asymmetric encryption |
|---|---|---|
| Keys used | One shared secret key encrypts and decrypts | A mathematically linked pair: public key and private key |
| Speed | Fast; suitable for bulk data | Far slower; unsuitable for large volumes |
| Core problem it creates | How do two parties share the key securely in the first place? | Computational cost |
| Core problem it solves | Efficient bulk confidentiality | Key distribution, plus digital signatures and non-repudiation |
| Key count for n users | n(n−1)/2 keys — grows quadratically | 2n keys — one pair per user |
| Current algorithms | AES (128/192/256-bit), ChaCha20 | RSA (2048-bit or larger), ECC/ECDSA, Diffie-Hellman |
| Deprecated algorithms | DES, 3DES, RC4, Blowfish (legacy) | RSA-1024 and smaller |
How they work together
Real systems use both, and understanding the handshake pattern answers a large share of exam items:
- The client and server use asymmetric cryptography to authenticate the server (via its certificate) and to agree on a shared secret without ever transmitting it in the clear.
- That shared secret becomes a symmetric session key.
- All of the actual traffic is then encrypted symmetrically, because it is orders of magnitude faster.
This is exactly what TLS does when you load an HTTPS page, and what IPsec does when an IKE exchange establishes a VPN tunnel. The one-line summary the exam wants: asymmetric for key exchange and authentication, symmetric for bulk data.
Which key does what
This is the classic trip-up. With an asymmetric key pair:
| Goal | Encrypt/sign with | Decrypt/verify with | Result |
|---|---|---|---|
| Confidentiality — only the recipient can read it | Recipient's public key | Recipient's private key | Only the holder of the private key can open it |
| Authenticity / non-repudiation — prove who sent it | Sender's private key (a digital signature) | Sender's public key | Anyone can verify it came from the key's owner and was not altered |
A private key is never shared, transmitted, or emailed. If a private key is exposed, the correct response is to revoke the associated certificate and generate a new key pair — not to "change the password on it."
Hashing vs. Encryption
| Hashing | Encryption | |
|---|---|---|
| Direction | One-way; cannot be reversed | Two-way; reversible with the key |
| Security goal | Integrity (and password storage) | Confidentiality |
| Output | Fixed-length digest, regardless of input size | Ciphertext roughly proportional to input size |
| Key required? | No key (HMAC adds one for authentication) | Yes |
| Typical use | File integrity verification, password storage, forensic evidence validation, digital signatures | Protecting files, disks, and network traffic |
Properties a hash function must have
- Deterministic — the same input always produces the same digest.
- Fixed-length output — SHA-256 always yields 256 bits whether the input is one byte or one terabyte.
- Avalanche effect — changing a single bit of input changes roughly half the output bits, so tampering is obvious.
- Preimage resistance — you cannot work backwards from a digest to the original data.
- Collision resistance — it must be infeasible to find two different inputs producing the same digest. MD5 and SHA-1 fail this and are therefore unsuitable for security use.
Password storage
Passwords are hashed, never encrypted — a system that could decrypt your password could also leak every password at once. Modern practice adds:
- Salt — a unique random value per user, hashed with the password, so identical passwords produce different digests and precomputed rainbow tables become useless.
- Key stretching / deliberately slow algorithms — bcrypt, scrypt, Argon2, or PBKDF2 — which make each guess computationally expensive and so cripple brute-force attempts.
Strong vs. Weak Algorithms
The blueprint explicitly asks you to distinguish strong from weak encryption algorithms. Learn this table as a recognition exercise: exam items often present an algorithm name and ask whether it should still be in use.
| Algorithm | Type | Status | Why |
|---|---|---|---|
| AES-128 / 192 / 256 | Symmetric | Strong — current standard | No practical break; hardware-accelerated on modern CPUs |
| ChaCha20-Poly1305 | Symmetric AEAD | Strong | Fast in software; common on mobile |
| RSA-2048 / 3072 / 4096 | Asymmetric | Strong at 2048 bits and above | RSA-1024 is no longer considered adequate |
| ECC / ECDSA / Ed25519 | Asymmetric | Strong | Equivalent security to RSA at much smaller key sizes |
| SHA-256, SHA-384, SHA-512, SHA-3 | Hash | Strong | No practical collision attacks |
| DES | Symmetric | Broken | 56-bit effective key; brute-forceable in hours |
| 3DES | Symmetric | Deprecated | Small block size and known weaknesses; formally retired for new use |
| RC4 | Symmetric stream | Broken | Biased keystream; prohibited in TLS |
| MD5 | Hash | Broken | Practical collisions; unsuitable for signatures or integrity assurance |
| SHA-1 | Hash | Broken | Practical collision demonstrated in 2017; retired from certificates |
| WEP | Wireless | Broken | Flawed RC4 initialisation vector reuse; recoverable key |
Exam tell: if an option names DES, 3DES, RC4, MD5, SHA-1, or WEP as the recommendation, it is almost certainly the wrong answer. These names appear as distractors precisely because they are still widely recognised.
The Three States of Data
The blueprint names states of data and appropriate encryption as an explicit requirement. Each state needs a different mechanism, and scenario items commonly test whether you can pick the right one.
| State | What it means | Typical protection | Real-world example |
|---|---|---|---|
| Data in transit | Moving across a network | TLS 1.2/1.3, IPsec, SSH, WPA3, VPN tunnels | An online banking session protected by HTTPS |
| Data at rest | Stored on disk, tape, backup media, or cloud storage | Full-disk encryption (BitLocker, FileVault, LUKS), database and file-level encryption, encrypted backups, self-encrypting drives | A stolen laptop whose BitLocker-encrypted drive is unreadable |
| Data in use | Loaded in memory and actively being processed by an application or CPU | Hardest to protect. Access controls, memory protection and process isolation, trusted execution environments (Intel SGX, AMD SEV, ARM TrustZone), homomorphic encryption in specialised cases, plus screen privacy filters and clean-desk policy for the human layer | A decrypted customer record sitting in application memory while a support agent views it |
Why data in use is the hard case: data must generally be decrypted before a CPU can operate on it, so the plaintext exists in RAM. That is precisely why memory-scraping malware, credential dumpers such as those targeting LSASS on Windows, and cold-boot attacks exist. Full-disk encryption protects a powered-off laptop; it protects nothing while the machine is unlocked and running.
Digital Certificates and Public Key Infrastructure
A public key is just a number. A digital certificate is a signed statement binding that public key to a verified identity — a hostname, an organisation, or a person — so you know whose key you are actually using.
What an X.509 certificate contains
- Subject — who the certificate identifies (e.g.
www.example.com) - Subject public key — the key being vouched for
- Issuer — the certificate authority that signed it
- Validity period — not-before and not-after dates
- Serial number — unique per issuing CA
- Signature algorithm and CA signature — the CA's cryptographic endorsement
- Extensions — key usage, Subject Alternative Names (SANs), CRL and OCSP endpoints
PKI components
| Component | Role |
|---|---|
| Certificate Authority (CA) | Issues and signs certificates; the trust anchor |
| Root CA | Top of the chain; its certificate is self-signed and pre-installed in operating systems and browsers. Kept offline in practice. |
| Intermediate / subordinate CA | Signed by the root and used for day-to-day issuance, so the root key stays offline. Compromise of an intermediate can be contained by revoking it. |
| Registration Authority (RA) | Verifies the requester's identity before the CA issues |
| Certificate Signing Request (CSR) | The request a subject sends, containing its public key and identifying details. The private key never leaves the subject. |
| CRL (Certificate Revocation List) | A periodically published list of revoked serial numbers |
| OCSP (Online Certificate Status Protocol) | Real-time revocation lookup; OCSP stapling lets the server present a recent signed status to avoid a client round-trip |
The chain of trust
When your browser validates https://www.example.com, it checks that the site certificate was signed by an intermediate CA, that the intermediate was signed by a root CA already in the local trust store, that no certificate in the chain has expired, that the hostname matches the Subject or a SAN entry, and that none of them has been revoked. Any single failure breaks the chain and produces the browser warning users are trained to click through — which is why certificate errors are a genuine security signal, not a nuisance.
Self-signed certificates provide encryption but no third-party identity verification, because the subject vouched for itself. They are acceptable on internal lab systems and unacceptable on anything public-facing.
Protocols That Use Encryption
The blueprint asks for protocols that use encryption, which in practice means recognising the secure replacement for each legacy cleartext protocol.
| Insecure protocol | Port | Secure replacement | Port | What the upgrade protects |
|---|---|---|---|---|
| HTTP | 80 | HTTPS (HTTP over TLS) | 443 | Web session content, cookies, credentials |
| FTP | 20/21 | SFTP (over SSH) or FTPS (over TLS) | 22 / 990 | File contents and login credentials |
| Telnet | 23 | SSH | 22 | Remote administration sessions |
| SMTP (plain) | 25 | SMTP with STARTTLS / SMTPS | 587 / 465 | Mail in transit between servers and clients |
| POP3 / IMAP | 110 / 143 | POP3S / IMAPS | 995 / 993 | Mailbox retrieval |
| SNMPv1/v2c | 161 | SNMPv3 | 161 | Device management data and community strings |
| DNS (plain) | 53 | DNSSEC (authenticity), DoT/DoH (confidentiality) | 53 / 853 / 443 | Resolution integrity and query privacy |
| LDAP | 389 | LDAPS or LDAP with StartTLS | 636 | Directory queries and bind credentials |
A precision point the exam likes: DNSSEC does not encrypt DNS. It cryptographically signs records so a resolver can verify they are authentic and unmodified — that is integrity and authenticity, not confidentiality. DNS over TLS (DoT) and DNS over HTTPS (DoH) are what provide confidentiality for queries.
A support technician must send a confidential file to a colleague using asymmetric encryption so that only that colleague can open it. Which key should be used to encrypt the file?
An administrator needs to verify that a downloaded installer has not been altered in transit. Which technique accomplishes this, and why?
A finance clerk's laptop has BitLocker full-disk encryption enabled. The laptop is stolen from a cafe while it is unlocked and logged in. Which state of data is exposed, and why did the encryption not prevent it?
During a security review, a technician finds an internal web server still configured to accept 3DES and RC4 cipher suites and presenting a SHA-1 signed certificate. What is the correct assessment?
What does DNSSEC provide that plain DNS does not?