Digital Signatures: Security+ exam prep and real-world

 Digital Signature

A Security+ (SY0-701) study guide to what digital signatures actually prove — and the exam traps built around them

Why this topic is an easy 5 points — if you don't fall for the trap

Digital signatures show up constantly on Security+, and the questions almost always hinge on one thing: candidates confuse a digital signature with encryption. They sound similar, they both involve keys and math, and a rushed test-taker will pick "confidentiality" as the answer almost on reflex. It's wrong almost every time.

The one sentence to memorize: A digital signature proves integrity, authentication, and non-repudiation — it does not, by itself, provide confidentiality.

Everything in this article builds toward being able to defend that sentence on the exam: what a digital signature is made of, how it's created and verified, how it differs from encryption and from a simple hash, how it relates to certificates and PKI, and the specific ways CompTIA likes to test it.

The two ingredients: hashing + asymmetric cryptography

A digital signature isn't a separate, exotic algorithm — it's a specific combination of two things you already need to know cold for Security+:

•         A cryptographic hash function (SHA-256, SHA-3, etc.) — takes an input of any size and produces a fixed-length digest. Change one bit of the input and the digest changes completely (the avalanche effect). Hashing is one-way: you can't reverse a digest back into the original message.

•         Asymmetric (public-key) cryptography (RSA, ECC/ECDSA, DSA) — a mathematically linked key pair where one key encrypts and only the other can decrypt. Each party has a private key (kept secret, never shared) and a public key (freely distributed).

Digital signatures use these two ingredients in a specific, reversed way compared to how you'd normally think about "public key encryption for confidentiality." That reversal is the whole trick, and it's worth sitting with:

For confidentiality: encrypt with the recipient's public key → only the recipient's private key can decrypt it. Many people can encrypt; only one person can read it. For a digital signature: sign with the sender's private key → anyone can verify it with the sender's public key. Only one person can create the signature; anyone can check it.

That second pattern — "only one person can produce it, anyone can check it" — is the definition of non-repudiation, and it's why signatures use the private key to sign, which trips up a lot of candidates who assume public-key crypto always means "encrypt with the public key."

How a digital signature is actually created

Walk through the steps in order — the exam sometimes asks you to sequence this process:

1.       The sender takes the original message and runs it through a hash function, producing a message digest.

2.       The sender encrypts that digest (not the whole message) with their own private key. The encrypted digest is the digital signature.

3.       The sender transmits the original message plus the attached signature.

Exam-critical detail: the signature is a hash of the message encrypted with the sender's private key — the message itself is usually sent in the clear alongside the signature. Signing does not hide the message content. If confidentiality is also required, the message must be separately encrypted (typically with the recipient's public key, or a symmetric session key) — signing and encrypting are two independent operations that are often combined but are not the same step.

How the recipient verifies it

1.       The recipient separates the received message from the attached signature.

2.       The recipient hashes the received message themselves, using the same hash function, producing their own digest.

3.       The recipient decrypts the signature using the sender's public key, recovering the original digest the sender computed.

4.       The recipient compares the two digests.

Comparison result	What it means
Digests match	Message is authentic (came from the holder of that private key) and unaltered in transit
Digests don't match	Message was altered, corrupted, or the signature doesn't belong to the claimed sender — reject it

If the digests match, three things are simultaneously proven, and Security+ wants you fluent in all three by name:

•         Integrity — the message weren't modified after signing (any change would change the hash).

•         Authentication — the message came from whoever holds the private key that matches the public key used to verify.

•         Non-repudiation — because only the private-key holder could have produced a signature that decrypts correctly with the matching public key, the sender cannot credibly deny having signed it.

What digital signatures do not provide

Confidentiality is not on that list. The message content travels with the signature and is readable by anyone who intercepts it unless it's separately encrypted. A question describing an unencrypted-but-signed message and asking "has confidentiality been achieved?" wants the answer no.

Two more nuances the exam likes to probe:

•         Availability isn't provided by signatures either — signing doesn't stop a message from being deleted or blocked in transit, only from being altered undetected.

•         Non-repudiation depends on private key control. If a private key is stolen, shared, or poorly protected, the non-repudiation guarantee collapses — the exam sometimes frames this as a justification for hardware security modules (HSMs) or smart cards to protect signing keys.

Digital signature vs. encryption vs. MAC/HMAC

This three-way comparison is one of the most heavily tested groupings in the whole Security+ cryptography domain:

	Digital Signature	Encryption	MAC / HMAC
Primary goal	Integrity, authentication, non-repudiation	Confidentiality	Integrity, authentication
Key type	Asymmetric (sign with private, verify with public)	Symmetric or asymmetric	Symmetric (shared secret key)
Provides non-repudiation?	Yes	No	No
Who can verify/decrypt?	Anyone with the public key	Only holder of the correct decryption key	Anyone with the shared secret key
Hides message content?	No (unless separately encrypted)	Yes	No

Why MAC/HMAC lacks non-repudiation but a digital signature has it: an HMAC uses one shared symmetric key known to both sender and receiver — either party could have generated it, so it proves the message came from "someone who knows the shared key," which includes the receiver. A digital signature uses a private key known to only the sender, so only the sender could have produced it. This distinction is a favorite exam trap: don't assume "it uses a hash and a key" automatically means non-repudiation.

Digital signatures vs. digital certificates vs. PKI

These three terms are related but answer different questions, and mixing them up costs points:

•         Digital signature — the cryptographic proof attached to one specific message or file, created with a private key.

•         Digital certificate — a document (typically X.509 format) that binds a public key to an identity (a person, server, or organization), issued and digitally signed by a Certificate Authority (CA). The certificate is what lets you trust that a given public key really belongs to the party it claims to.

•         Public Key Infrastructure (PKI) — the whole ecosystem: CAs, registration authorities (RAs), certificate repositories, certificate revocation lists (CRLs) / OCSP, and the policies that govern issuing, validating, and revoking certificates.

How they connect: you verify a digital signature using someone's public key — but how do you know that public key actually belongs to them, and not an attacker? That's what the digital certificate answers, and the CA's own signature on the certificate is what makes it trustworthy, assuming you trust the CA (directly, or via a chain of trust back to a trusted root).

This chain — root CA → intermediate CA → end-entity certificate — is itself a favorite SY0-701 diagram-style question: know that trust flows downward from a root CA, that an intermediate CA exists partly to keep the root CA's private key offline and protected, and that a certificate revocation list (CRL) or OCSP (Online Certificate Status Protocol) is how you check whether a certificate has been revoked before its expiration date.

Algorithms you should recognize (not derive)

Security+ tests recognition, not math. Know these by name and rough category:

Algorithm	Type	Notes
RSA	Asymmetric, used for signing and encryption	Oldest, widely deployed, larger key sizes needed for equivalent security
DSA (Digital Signature Algorithm)	Asymmetric, signing only	U.S. federal standard (FIPS 186), not used for encryption
ECDSA (Elliptic Curve DSA)	Asymmetric, signing only	Same purpose as DSA, smaller keys for equivalent strength — common in mobile/IoT
EdDSA	Asymmetric, signing only	Newer elliptic-curve signature scheme, used in modern protocols (e.g., SSH, TLS 1.3)
SHA-256 / SHA-3	Hash function (not a signature algorithm itself)	The hashing half of the signing process, paired with one of the above

Where digital signatures live in the SY0-701 objectives

Digital signatures fall under Domain 1.0 – General Security Concepts, inside the cryptographic solutions material, alongside public key infrastructure, asymmetric/symmetric encryption, hashing, salting, key escrow, and certificates. Expect the exam to test this material through scenario questions rather than definitions alone — for example, describing an email that needs to be provably sent by a specific person and asking which control (digital signature, encryption, hashing alone, or a MAC) satisfies that requirement.

Non-repudiation itself also appears as a named security concept in the same domain, usually paired directly with digital signatures as the mechanism that achieves it — if a question defines non-repudiation and asks which technology provides it, digital signatures are almost always the correct choice over encryption, hashing, or access control lists.

Common exam gotchas, summarized

•         "Digitally signed" does not mean "encrypted." A signed message can still be read by anyone who intercepts it unless separately encrypted.

•         Signing uses the sender's private key; verifying uses the sender's public key. This is the reverse of the "encrypt with recipient's public key" pattern used for confidentiality — mixing these up is the single most common mistake.

•         The signature is computed over a hash of the message, not the raw message. This is what makes signatures efficient even for large files.

•         Non-repudiation requires the private key to stay private. A shared or compromised private key breaks the guarantee.

•         MACs and HMACs provide integrity and authentication but not non-repudiation, because they rely on a symmetric key both parties possess.

•         A digital certificate is not the same thing as a digital signature — a certificate binds an identity to a public key (via a CA's signature on the certificate); a digital signature is applied to a specific message using that identity's private key.

Practice-style questions

1. A company needs to ensure that a signed contract sent by email cannot later be denied by the sender. Which property of digital signatures specifically addresses this? Non-repudiation — because only the sender's private key could have produced a valid signature, the sender cannot credibly deny signing.

2. An analyst notices that a digitally signed file is being transmitted in plaintext and asks whether the file's contents are protected from eavesdropping. What is the correct answer? No — a digital signature provides integrity, authentication, and non-repudiation, but not confidentiality; the file itself must be separately encrypted to protect its contents.

3. Which key is used to create a digital signature, and which key is used to verify it? The signer's private key creates the signature; the signer's public key verifies it.

4. Why does an HMAC not provide non-repudiation, even though it uses a secret key and produces a fixed-length output similar to a digital signature? Because an HMAC relies on a symmetric key shared by both parties — either party could have generated the MAC, so it cannot prove which of the two actually sent the message. A digital signature uses a private key known only to the sender, which is what enables non-repudiation.

Quick-reference cheat sheet

Concept	One-line definition
Digital signature	Hash of a message encrypted with the sender's private key; verified with the sender's public key
Provides	Integrity, authentication, non-repudiation
Does not provide	Confidentiality, availability
Signing key	Sender's private key
Verifying key	Sender's public key
Digital certificate	Binds a public key to an identity, signed by a CA
PKI	The full trust ecosystem: CAs, RAs, CRLs/OCSP, certificate lifecycle
MAC/HMAC	Integrity + authentication via a shared symmetric key — no non-repudiation

Further study: NIST FIPS 186-5 (Digital Signature Standard) and CompTIA's official SY0-701 exam objectives document for the authoritative, current wording of Domain 1.0.