A cryptographic hash, a message authentication code, and a digital signature can all detect a changed message, but they do not establish the same facts. The difference is not the length of the output or whether a hash function appears inside the construction. It is who possesses which key and what a verifier can prove afterward.
The most common exam error is to say that a secure MAC provides non-repudiation. It does not: every party that can verify a conventional MAC also knows the shared key needed to generate a valid one.
Compare the Four Main Tools
| Mechanism | Secret input | Detects modification | Authenticates origin | Supports third-party verification | Encrypts content |
|---|---|---|---|---|---|
| Cryptographic hash | None | Only against an independently trusted reference | No | No | No |
| MAC, such as HMAC, KMAC, or CMAC | Shared symmetric key | Yes | Yes, to another key holder | No | No |
| Digital signature | Signer’s private key; verifier uses public key | Yes | Yes, subject to key identity | Yes, with the required identity and evidence controls | No |
| Authenticated encryption, such as AES-GCM | Shared symmetric key | Yes | Yes, to another key holder | No | Yes |
NIST’s MAC glossary states the boundary directly: MACs provide authenticity and integrity, but not non-repudiation. NIST’s MAC project currently lists HMAC, KMAC, and CMAC as approved general-purpose MAC families.
A Hash Is Not Authentication
Suppose a software vendor publishes an installer and places its SHA-256 value on the same compromised download server. An attacker who replaces the installer can also replace the unkeyed hash. The digest still detects an accidental transfer error, but it does not identify who published the file.
A hash becomes meaningful for security when the expected value arrives through an independently trusted channel or participates in a keyed or signed construction. Examples include a digest embedded in a signed release manifest, a certificate-authenticated protocol, or a trusted package repository.
Collision resistance means it should be computationally infeasible to find two different inputs with the same digest. Making collisions easy to find weakens a hash; it never secures it. Preimage resistance is different: given a digest, it should be infeasible to recover an input producing it. A question about one property cannot automatically be answered with the definition of the other.
How a Message Authentication Code Works
Alice and Bob share a symmetric key. Alice applies a MAC algorithm to the message and key, then sends the message and tag. Bob recomputes the tag with the same key and compares it using a constant-time verification function.
If verification succeeds, Bob knows two useful things:
- The protected bytes did not change after a party holding the key created the tag.
- A party possessing the shared key generated the tag.
What Bob cannot demonstrate to an independent judge is that Alice, rather than Bob, generated it. Both possess the capability. This is why a MAC authenticates among key holders but does not provide conventional non-repudiation.
Do not invent a MAC by concatenating a secret and a hash. Use a standard construction such as HMAC with an approved hash, KMAC, CMAC, or an authenticated-encryption API. Protocol details including tag length, key separation, replay handling, and canonical message encoding still matter.
How a Digital Signature Changes the Evidence
With a digital-signature system, the signer controls a private key and verifiers use the corresponding public key. A verifier cannot normally create another valid signature with the public key. This asymmetry allows verification beyond the original recipient.
NIST’s FIPS 204 describes digital signatures as detecting unauthorised modification, authenticating the signatory, and providing evidence that can support non-repudiation. FIPS 204 standardises ML-DSA, a post-quantum signature scheme; the security property is broader than that one algorithm.
“Supports non-repudiation” is not the same as “legally proves a human approved this action.” Operational evidence also depends on:
- reliable binding between the public key and the claimed identity;
- protection and exclusive control of the private key;
- certificate validity and revocation evidence;
- trustworthy timestamps when timing matters;
- audit records showing what exact bytes were presented for signing;
- policy and legal rules for the relevant organisation or jurisdiction.
If a private signing key is copied among a team, the cryptographic signature may verify while individual attribution remains weak.
MACs and Signatures Do Not Prevent Replay
An attacker may capture a valid authenticated request and send it again. The MAC or signature still verifies because the message is unchanged.
A protocol prevents replay by authenticating freshness data such as a nonce, sequence number, transaction identifier, timestamp with a defined acceptance window, or session context. The verifier must store or otherwise enforce the relevant state. Adding an unauthenticated timestamp beside the tag achieves nothing because an attacker can replace it.
The signed or MACed structure must unambiguously include:
protocol version | sender context | recipient context | operation | parameters | freshness value
Canonical encoding is essential. If sender and verifier serialise the same fields differently, verification fails; if fields can be interpreted in two ways, a valid tag may authorise the wrong operation.
Encryption Is a Separate Property
Neither a MAC nor a digital signature hides the message. A signed document remains readable, and a MACed API body remains readable to anyone who can observe it.
When two parties share a key and need confidentiality plus integrity, prefer a standard authenticated-encryption mode such as AES-GCM or an established protocol that uses one correctly. Do not encrypt first and then improvise a separate authentication format unless a reviewed protocol specifies the composition.
Signatures are often combined with encryption when third-party-verifiable origin and confidentiality are both required, but the order, recipient binding, and metadata protection must be defined by the protocol—not guessed per application.
Key Management Determines the Real Security
A strong primitive with poor key handling produces weak security. Separate keys by purpose and environment. Do not reuse one symmetric key for encryption, MAC generation, backups, and test systems. Rotate keys according to policy, restrict access, record key versions, and design verification so older messages remain interpretable when required.
For signatures, protect the private key in an appropriate hardware or operating-system keystore when the risk justifies it. For MACs, limit the number of verifiers because every verifier is also capable of generating tags. If thousands of devices share one MAC key, compromise of one can undermine the entire group.
Choose by the Claim You Need to Establish
Use a hash when you need a compact fingerprint and can obtain the expected value from a trusted source. Use a MAC when mutually trusted systems share a key and need efficient integrity and source authentication. Use a digital signature when many parties must verify one signer’s output or when third-party evidence is required. Use authenticated encryption when the same trusted parties need confidentiality and integrity together.
The decisive question is not “which algorithm is strongest?” It is “who must be able to create, verify, and later prove this result?” Once those roles are explicit, the correct construction is usually clear.