Cryptography and PKI Fundamentals
Apply symmetric and asymmetric cryptography, hashing, and certificates to protect data in transit and at rest.
- Certification
- CompTIA Security+
- Recommended study time
- 6h 35m
- Status
- Not started
Recommended study time
About 6h 35m in total, measured from the material on this page. At your session length of 45 minutes that is 9 sittings.
- Read the lesson23 min
About 2,978 words at a careful technical reading pace.
- Second pass with notes14 min
Re-read the harder parts and write your own notes.
- Recall from memory12 min
2 written recall questions.
- Practice decision12 min
One applied decision with feedback.
- Teach it back20 min
Write the topic in your own words.
- Real-world scenario15 min
Read the situation and justify your decision in writing.
- Hands-on practice3h 20m
Labs, commands and configuration until you can do it unaided.
- Spaced review1h 40m
4 short review sessions spread over the following weeks.
Learning objectives
- Choose between symmetric, asymmetric, and hashing for a stated requirement.
- Explain certificate issuance, validation, and revocation in a PKI.
- Diagnose common TLS and certificate errors accurately.
Start here
About 8 minutes of reading, in 10 short parts.
Cryptography is the mathematics that makes confidentiality and integrity actually possible on a network where anyone could, in principle, intercept traffic. You do not need to be a mathematician to use it well, but you do need to know the difference between the major techniques and when each one is the right tool.
Where you meet it: A developer asks whether to store passwords encrypted or hashed, and the correct answer, hashed with a strong algorithm and salt, depends on understanding exactly what each cryptographic technique guarantees.
The lesson, part by part
Open one part at a time. Each part stands on its own, so you can stop and come back.
Encryption is like putting a letter in a locked box: anyone can see the box travelling, but only someone with the right key can open it and read the contents. Symmetric encryption uses the same key to lock and unlock the box, which is fast but means both people need to already share that key safely. Asymmetric encryption uses two different keys, a public one anyone can use to lock the box and a private one only the owner has to unlock it, solving the problem of sharing a secret key in advance.
Hashing is a completely different idea: instead of locking something so it can be unlocked later, hashing turns data into a short fixed-length fingerprint that cannot be reversed back into the original. It is used to prove something has not changed, the way a wax seal on an envelope proves nobody has opened and resealed it, not to keep the contents secret.
Key ideas
If you remember nothing else from this topic, remember these.
- Symmetric encryption uses a single shared key for both encryption and decryption, making it fast but requiring a secure way to distribute that key in advance.
- Asymmetric encryption uses a mathematically linked public and private key pair, solving the key distribution problem at the cost of significantly more computation.
- Hashing produces a fixed-length, one-way digest used to verify integrity, and a good hash function makes it computationally infeasible to find two inputs that produce the same output.
- TLS combines both approaches: asymmetric cryptography establishes a shared session key during the handshake, then symmetric encryption protects the bulk of the actual data using that session key.
- Digital certificates bind a public key to an identity and are validated through a chain of trust back to a trusted root certificate authority.
- Digital signatures use the sender's private key to sign a hash of a message, letting anyone with the sender's public key verify both authenticity and integrity.
Walking through a TLS 1.2 handshake step by step
A worked example, step by step.
A browser connects to https://example.com and must establish a secure session before any page data is exchanged.
- 01ClientHelloThe browser sends a ClientHello message listing supported TLS versions, cipher suites, and a random value.
- 02ServerHelloThe server responds with a ServerHello, selecting a cipher suite from the client's list and sending its own random value.
- 03CertificateThe server sends its digital certificate, containing its public key and identity, signed by a certificate authority.
- 04Certificate validationThe browser checks the certificate chain up to a trusted root CA in its trust store, and confirms the domain name matches and the certificate has not expired or been revoked.
- 05Key exchangeThe client generates a pre-master secret, encrypts it with the server's public key from the certificate, and sends it to the server.
- 06Session key derivationBoth sides independently derive the same symmetric session key from the pre-master secret and the earlier exchanged random values.
- 07Finished messagesBoth client and server send encrypted Finished messages using the new session key to confirm the handshake completed correctly.
- 08Application dataAll subsequent HTTP traffic is encrypted using fast symmetric encryption with the negotiated session key rather than the slower asymmetric keys.
Outcome: Asymmetric cryptography was used only briefly to safely exchange a shared secret, after which fast symmetric encryption protected the actual browsing session, illustrating why TLS uses both.
Cryptographic algorithms and concepts
Worth keeping at hand while you work.
- AES
- Symmetric block cipher, current standard, commonly used at 128 or 256-bit key length
- 3DES
- Older symmetric cipher, largely deprecated in favour of AES
- RSA
- Asymmetric algorithm used for key exchange and digital signatures
- ECC (Elliptic Curve Cryptography)
- Asymmetric algorithm offering equivalent security to RSA with much smaller key sizes
- Diffie-Hellman
- Key exchange algorithm allowing two parties to derive a shared secret over an insecure channel
- SHA-256
- Modern secure hashing algorithm, produces a 256-bit digest
- MD5
- Older hashing algorithm, cryptographically broken, should not be used for security purposes
- HMAC
- Combines a hash function with a secret key to verify both integrity and authenticity
- Digital signature
- A hash of a message encrypted with the sender's private key to prove authenticity and integrity
- Certificate authority (CA)
- Trusted entity that issues and signs digital certificates
- Chain of trust
- The path of certificate signatures from a server certificate up to a trusted root CA
- PFS (Perfect Forward Secrecy)
- Ensures session keys cannot be recovered even if the server's long-term private key is later compromised
Common misunderstandings
What most beginners get wrong here.
TLS uses only asymmetric encryption for the entire session.
TLS uses asymmetric cryptography only briefly during the handshake to establish a shared secret, then switches to faster symmetric encryption for the bulk of the session.
Hashing and encryption are the same thing because both scramble data.
Encryption is reversible with the correct key, while a properly designed hash function is one-way and cannot be reversed to recover the original input.
A digital signature encrypts the entire message with the sender's private key.
A digital signature typically encrypts a hash of the message with the private key, not the entire message, which keeps the process efficient.
MD5 is still acceptable for verifying file integrity in security-sensitive contexts.
MD5 is cryptographically broken due to demonstrated collision attacks and should be replaced with SHA-256 or stronger for any security-relevant integrity check.
A longer symmetric key always requires proportionally more computing time than a shorter asymmetric key of the same length.
Symmetric algorithms are inherently far faster than asymmetric algorithms at comparable security strength, which is exactly why TLS reserves asymmetric operations for the handshake only.
Exam traps
How the question writers try to catch you out.
- Security+ frequently asks which algorithm category, symmetric or asymmetric, a named algorithm belongs to, expecting recall of AES and 3DES as symmetric versus RSA and ECC as asymmetric.
- Expect scenario questions about verifying a downloaded file's integrity, where the correct answer involves comparing a SHA-256 hash rather than encrypting the file.
- Handshake-ordering questions test whether you know certificate validation happens before the session key is used for application data.
- Distractor answers often confuse a digital signature (uses the signer's private key) with encryption for confidentiality (uses the recipient's public key).
- Perfect Forward Secrecy questions test understanding that compromising a server's long-term private key later should not expose past recorded session traffic.
- MD5 and SHA-1 frequently appear as intentionally wrong answers in questions about currently recommended hashing algorithms.
Check yourself
Answer in your head first, then reveal. This is not scored.
Why does TLS use both symmetric and asymmetric cryptography instead of just one?
What makes a digital signature different from simple encryption?
Why is MD5 no longer considered acceptable for security purposes?
What does Perfect Forward Secrecy protect against?
What is validated when a browser checks a server's certificate chain of trust?
Why is asymmetric encryption not used for the entire TLS session's data?
Quick reference
A condensed summary of the lesson above, for revision.
What It Is
Symmetric encryption such as AES uses one shared key and is fast, suiting bulk data. Asymmetric cryptography such as RSA or ECC uses a key pair, enabling key exchange and digital signatures. Hashing such as SHA-256 produces a one-way fingerprint for integrity. A public key infrastructure issues certificates binding identities to public keys, validated through a chain to a trusted root and checked against revocation.
Why It Matters
TLS errors, VPN failures, code signing, password storage, and disk encryption all rest on these primitives. Misapplying them, such as hashing without salting or trusting an unvalidated certificate, produces confident but broken security.
How It Works
- A TLS handshake authenticates the server certificate, agrees parameters, and derives session keys.
- Signatures are produced with a private key and verified with the matching public key.
- Clients validate a chain to a trusted root and check validity dates and revocation.
Where You See It
- HTTPS, VPNs, email signing, code signing, disk encryption, and API authentication.
Key Terms
- Symmetric key
- A single shared secret used to encrypt and decrypt.
- Digital signature
- A private-key operation proving origin and integrity.
- Salt
- Random data added before hashing to defeat precomputed tables.
- Certificate chain
- The path from a leaf certificate to a trusted root.
- Revocation
- Invalidating a certificate before expiry through CRL or OCSP.
Examples
- TLS uses asymmetric cryptography to agree a session key, then symmetric encryption for the data.
- Password storage should use a slow salted algorithm such as bcrypt or Argon2, not plain SHA-256.
Common Problems
- Expired certificate
- Name mismatch
- Missing intermediate certificate
- Untrusted internal CA
- Weak or deprecated cipher
How It Fails
- A missing intermediate works in browsers with cached chains but fails for API clients.
- System clock errors make valid certificates appear expired.
- Self-signed certificates train users to click through warnings.
How to Troubleshoot
- Read the exact error: expiry, name, chain, and revocation each mean different fixes.
- Verify the served chain from the server side rather than only in a browser.
- Check time synchronisation before assuming certificate corruption.
Practical Knowledge
- Track certificate expiry with monitoring and automation, not calendar reminders.
- Distribute the internal root CA through device management so internal services validate cleanly.
Exam Coverage
- Cryptographic primitives and use cases
- PKI, certificates, and trust chains
- TLS troubleshooting
Interview Questions
- Why does TLS use both asymmetric and symmetric cryptography?
- What causes a 'certificate name mismatch' error?
Watch and read
Verified official and reputable sources for this topic. Links open in a new tab.
Video training
Lesson notes and bookmark
Notes and bookmarks for this lesson, saved with everything else you have marked.
No notes on this item yet.
Learning progress
0% across six evidence areas. Reading alone does not change progress.
Prerequisites
Next steps
- 01Inspect a website certificate chain and note issuer, validity, and SANs.
- 02Explain in writing why hashing alone cannot protect confidentiality.