Study guide
2.6 Encryption, Hashing, Certificates & PKI
Cisco CCST Cybersecurity Exam
Track your progress as you read
Finished sections get a check mark.
1 Chapter 1: Introduction & Exam Strategy
1.1 About the Cisco CCST Cybersecurity Exam 1.2 Study Roadmap & Preparation Strategy
2 Chapter 2: Essential Security Principles
2.1 Information Security Principles & The CIA Triad 2.2 Confidentiality, Integrity & Availability Controls 2.3 Authentication, Authorization & Accounting (AAA) 2.4 Social Engineering & Human Vulnerabilities 2.5 Security Principles & Access Management 2.6 Encryption, Hashing, Certificates & PKI
3 Chapter 3: Basic Network Security Concepts
3.1 Network Architecture & The OSI/TCP-IP Models 3.2 Network Defense Infrastructure & Firewalls 3.3 Intrusion Detection & Prevention Systems (IDS/IPS) 3.4 Virtual Private Networks & Encryption Protocols 3.5 Network Segmentation, DMZ & Access Control Lists 3.6 Secure Network Protocols & Services
4 Chapter 4: Endpoint Security Concepts
4.1 Endpoint Protection & Host-Based Defense 4.2 Operating System Hardening & Security Baselines 4.3 Patch Management & Vulnerability Remediation 4.4 Mobile Device Management (MDM) & BYOD Security 4.5 Endpoint Detection & Response (EDR) & Compliance 4.6 Endpoint Assessment Tools & Malware Removal
5 Chapter 5: Vulnerability Assessment & Risk Management
5.1 Risk Assessment & Risk Management 5.2 Vulnerability Scanning & Penetration Testing 5.3 CVSS Scoring & Threat Intelligence 5.4 Business Continuity & Disaster Recovery
6 Chapter 6: Incident Handling & Response
6.1 NIST Incident Response Lifecycle & Frameworks 6.2 Incident Containment, Eradication, & System Recovery 6.3 Digital Forensics Fundamentals & Evidence Preservation 6.4 Post-Incident Activity & Compliance Reporting 6.5 SOC Operations, Log Triage, & Event Monitoring 6.6 Attack Attribution: Cyber Kill Chain, MITRE ATT&CK & Diamond Model
2.6 Encryption, Hashing, Certificates & PKI
Key Takeaways Explain This Topic AI
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.
Last updated: August 2026
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.