Digital Signatures in Practice(OBJ.1.3)

Every month, millions of Windows computers download updates through content delivery networks and install them with full system privileges. What makes that reasonable is not the download link or the server it came from. Before installing anything, each machine checks a digital signature that proves the update came from the vendor and hasn't been altered since it was signed.

On the CompTIA Security+ SY0-801 exam, digital signatures are part of objective 1.3, which expects you to explain why the right cryptographic solution matters. This lesson covers how signing and verification work, what a signature proves and what it doesn't, and where you'll meet signatures on the job: in code, software updates, email and documents.

A signature is a hash signed with the signer's private key

A digital signature combines the two ideas from earlier in the course: hashing and asymmetric key pairs. Creating one takes three steps:

1. The signing software hashes the content, usually with SHA-256 or stronger.
2. The signer's private key is used to sign that hash. With RSA this is often described as encrypting the hash with the private key. ECDSA and EdDSA use different mathematics and don't encrypt anything, but the result is the same: a value only the private key could have produced.
3. The signature, and usually the signer's certificate, is attached to the content or shipped beside it.

The content is hashed first for practical reasons. Asymmetric operations are slow and can only handle small inputs, so signing a 32-byte digest works the same for a one-line email or a 4 GB installer. It also explains why collision resistance matters so much. The signature covers the hash, so if two documents share a hash, they share a signature. That is how the Flame malware turned an MD5 collision into a forged Microsoft-chained certificate, and why signatures today use SHA-256 or stronger.

Current signature algorithms are RSA with 2048-bit or larger keys (3072-bit or larger for long-lived keys), ECDSA on the P-256 or P-384 curves, and EdDSA, most often as Ed25519. The older DSA standard is no longer approved for creating new signatures under NIST's FIPS 186-5.

On the exam, the signer always uses their own private key. Answers that sign with a public key, or with the recipient's key, are wrong.

Verification recomputes the hash and checks it with the public key

Anyone with the signer's public key can verify a signature. The verifier's software does two things:

1. It hashes the received content with the same algorithm the signer used.
2. It uses the signer's public key to check the signature against that new hash.

If they match, two things are true at once: the content hasn't changed by a single bit since it was signed, and the signature was made by whoever holds the matching private key. If anything was altered, the hashes differ and verification fails.

Here is a detached signature check on a Linux release archive with GnuPG:

$ gpg --verify agent-4.2.1.tar.gz.asc agent-4.2.1.tar.gz
gpg: Signature made Wed Oct 14 09:12:44 2026 UTC
gpg:                using RSA key 7D2A40C1E58B3F96A0D4E1B2C3F591C46B8E02D7
gpg: Good signature from "Example Corp Release Signing <release@example.com>" [unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg:          There is no indication that the signature belongs to the owner.

"Good signature" means the math checks out: the archive matches what the key holder signed. The warning is about a different question, whether this public key really belongs to Example Corp. Binding public keys to verified identities is the job of certificates and PKI, which are covered in the next section.