CompTIA Security+ guideHigh-value skills
Security+ Cryptography and PKI Explained
Follow one software download through encryption, hashing, a signature, and a certificate, and see what each one does not prove.
Short answer
Encryption hides a file in transit. A hash shows whether the bytes changed. A digital signature shows that the holder of a private key approved that exact hash. A certificate binds a public key to a name if you trust the certificate authority that signed it. None of those jobs replaces the others. SY0-701 lists them as separate cryptographic solutions.
One download, four different jobs
A clinic publishes a scheduling tool. You download scheduler.exe over the internet. Four questions come up, and they are not the same question.
| Security goal | Mechanism | Material involved | What it does not establish |
|---|---|---|---|
| Hide the file while it moves | Encryption | A secret key, or a public key used only to protect a key | Who published the file, or that nobody changed it after decryption |
| Notice that the bytes changed | Hash | The file itself. No key is required for a plain hash | Who created it. A hash published beside an untrusted file can be swapped with the file |
| Show that a specific key holder approved those exact bytes | Digital signature | Signer private key. Verifier uses the matching public key | That the name on the website is the real publisher, until a trusted certificate binds that key |
| Bind a public key to a publisher name | Certificate | CA signature over the subject name and public key | That the file is safe to run, or that the computer is uninfected |
SY0-701 lists public key infrastructure, symmetric and asymmetric encryption, key exchange, hashing, digital signatures, certificate authorities, certificate revocation lists, and OCSP as separate ideas. The acronym guide is the short pair list. This page is the choice.
How the pieces fit on this download
Encryption. The transfer can use TLS so a listener on the path cannot read the bytes. Symmetric encryption is fast for the file or the session. Asymmetric encryption is slower and is used to help the two sides agree on secrets or to prove a key, not to bulk-encrypt a large installer by itself. TLS 1.3, in RFC 8446, uses ephemeral Diffie-Hellman for key agreement and a signature to authenticate that agreement. It does not work by “the server encrypts the session key with its private key.” Do not treat that older story as how current TLS behaves.
Hashing. After the download, a SHA-256 digest of the file will change if any byte changes. That detects modification. It is not encryption, and it does not say who made the file. If the attacker can change the file and the published digest together, both still match.
Signature. The publisher hashes the file and produces a signature with a private key. You check it with the public key. That ties the hash to the key holder. It is a signature operation, not a universal rule that “signing means encrypting with the private key.” ECDSA and EdDSA are signature algorithms. They are not encryption run backwards. A matching signature still does not tell you the key belongs to the clinic until something trustworthy says so.
Certificate. RFC 5280 describes a certificate as a binding between a public key and a subject, signed by an issuer. You trust it when that issuer sits in a chain that ends at a root you already trust. SY0-701 names certificate authorities, root of trust, certificate signing requests, self-signed certificates, third-party certificates, CRLs, and OCSP. A CRL or an OCSP response is how a verifier can learn that a certificate was revoked. A self-signed certificate has no such issuer. It can be fine for a lab you configured yourself. It does not give a stranger a reason to trust the clinic’s name.
Four short choices
1. The installer must be unreadable on the cafe network. Which mechanism? Encryption of the transfer. A hash of the file does not hide it.
2. You already have the file and only need to know whether it matches last week’s copy. Which mechanism? A hash you computed earlier, or a hash from a source you already trust. A new hash sitting next to a new file does not help if both could have been replaced.
3. You need to know the clinic’s key holder approved this exact build. Which mechanism? A digital signature checked with that public key. The hash alone does not name the publisher.
4. You have a public key and need a reason to believe it is the clinic’s. Which mechanism? A certificate that chains to a root you trust, and a revocation check that does not say the certificate was revoked. The signature on the file cannot create that binding by itself.
Practice a Security+ item that separates a hash from a signature. The free set is multiple choice. It will not open a certificate viewer.
Trust the source
Official sources
Exam policies can change. Use these primary sources for the most current details.