How Hashes, MACs, and Signatures Differ | IoT Worker

How Hashes, MACs, and Signatures Differ

Reading time: 7 minute Word count: 1346
Cryptography Security Hash HMAC Digital Signatures

A dangerous sentence appears often in device security designs: “We use SHA-256, so it is secure.”

That is usually incomplete. SHA-256 is a hash function. It turns data into a fixed-size digest, but it does not know who computed it and cannot stop an attacker from modifying data and recomputing the digest.

Hashes, MACs, and signatures all output values that look like checksums, but they solve different problems:

Hash: did the data match this fingerprint, assuming the digest itself is trusted
MAC: was this generated by someone holding the same shared key
Signature: was this generated by a private-key holder, verifiable by public key

Mixing them up directly affects firmware verification, device authentication, message integrity, and audit logs.

A Hash Is a Fingerprint, Not Authentication

A hash function turns arbitrary input into a fixed-size digest:

message -> SHA-256 -> digest

It fits:

  • file fingerprints
  • firmware integrity digests
  • deduplication and indexing
  • Merkle trees
  • digesting data before signing
  • public checksum comparison after download

A hash answers: “Does this data match this digest?”

It does not answer:

  • who provided the digest
  • whether the digest was modified too
  • whether the data came from a trusted device
  • whether the sender holds a key

If an attacker can modify both the file and the hash, a hash alone gives no protection.

firmware.bin
firmware.bin.sha256

If both files come from the same untrusted channel, the attacker can replace the firmware and generate a new .sha256. Verification passes, but it verified the attacker’s digest.

So a hash must be tied to a trusted source: a trusted release page, a signature, a certificate, read-only storage, Secure Boot metadata, or another trusted channel.

A MAC Authenticates With a Shared Key

MAC means Message Authentication Code. It uses a shared key to produce an authentication tag:

message + shared key -> HMAC/CMAC -> tag

The verifier also holds the same shared key:

message + shared key -> recompute tag -> compare

A MAC proves that the message was generated by someone holding the shared key and was not modified.

Common algorithms include:

  • HMAC-SHA256
  • AES-CMAC
  • Poly1305

MACs fit:

  • shared-key authentication between device and server
  • internal message integrity
  • protocol packet authentication
  • tamper protection for tokens or configuration
  • lightweight authentication inside an existing secure channel

The key boundary is that the verifier can also generate the same tag. Since both sides share the key, a MAC cannot prove which side generated the tag. It proves only that a key holder generated it.

That is often enough for device-to-server authentication, but not enough for public verification, third-party audit, or non-repudiation.

A Signature Uses Private Key and Public Verification

Digital signatures use asymmetric keys:

message + private key -> signature
message + public key + signature -> verify

Only the signer holds the private key. The public key can be distributed to verifiers. A verifier can confirm the signature was produced by the corresponding private key but cannot forge signatures with the public key.

Common algorithms include:

  • ECDSA P-256
  • Ed25519
  • RSA-PSS

Signatures fit:

  • firmware signing
  • Secure Boot
  • OTA package verification
  • device certificate chains
  • logs or audit records
  • third-party-verifiable authorization claims

The main difference from MAC is trust distribution.

A MAC requires the verifier to hold the shared secret. A signature requires only a public key. That makes signatures better for “many devices verify one publisher” scenarios.

For firmware verification, devices store the vendor public key or certificate chain. The release system signs firmware with the private key. Devices can verify but cannot forge vendor signatures.

If MAC were used instead, each device would need material that can generate valid tags. If that material leaks from one device, forgery risk spreads.

They Do Not Solve the Same Problem

Use this as a first comparison:

Hash
    Input: data
    Key: none
    Verifier: anyone
    Proves: data matches digest
    Risk: digest must itself be trusted

MAC
    Input: data + shared key
    Key: shared by both sides
    Verifier: same key holder
    Proves: message came from a key holder and was not modified
    Risk: verifier can also forge; key leakage affects both sides

Signature
    Input: data + private key
    Key: private key signs, public key verifies
    Verifier: public key holder
    Proves: message was signed by the private-key holder and was not modified
    Risk: private-key protection and public-key trust chain are central

In one line:

Hash is a fingerprint
MAC is shared-key authentication
Signature is publicly verifiable identity binding

Do Not Build a MAC by Concatenating a Key and a Hash

Some implementations write:

SHA256(key || message)

or:

SHA256(message || key)

That is not a recommended MAC design.

Ordinary hash functions are not designed directly as message authentication codes. Some constructions run into length-extension attacks, boundary ambiguity, concatenation ambiguity, or protocol evolution problems.

HMAC wraps a hash function into a secure MAC construction:

HMAC(key, message)

Do not invent key-plus-message hashing. If a MAC is needed, use HMAC, CMAC, or the authentication algorithm specified by the protocol.

Firmware Integrity Usually Needs Signatures

Firmware security has three layers:

First, hash. It confirms firmware matches a digest, but the digest must be trusted.

Second, MAC. It confirms firmware was authenticated by someone holding the shared key, but the verifier also holds that key.

Third, signature. The publisher signs with a private key and devices verify with a public key. Devices can verify but cannot forge publisher signatures.

This is why Secure Boot and OTA verification usually use digital signatures, not only a hash and not one shared MAC key across devices.

Hashes still participate, usually as the input to signing:

firmware -> hash -> sign hash
device -> hash firmware -> verify signature

The signature protects the claim that a trusted private key authorized the digest.

Message Authentication Often Uses MAC

If a device and server already share a secret, MAC is a good fit for message authentication.

Example device report:

device_id
timestamp
counter
payload
tag = HMAC(device_key, fields)

After verifying the tag, the server knows the message came from a holder of device_key and that fields were not modified.

Important boundaries:

  • MAC does not encrypt payload; use encryption or AEAD for confidentiality
  • MAC must cover all security-critical fields
  • timestamp/counter/nonce is needed against replay
  • tag comparison should avoid timing leaks
  • if the shared key leaks, attackers can forge messages

MAC is authentication, not encryption and not automatic replay protection.

Certificate Chains Are Signature Chains

Device certificates, server certificates, and CA certificates all rely on signatures.

A device certificate roughly says:

CA private key signed: this device public key belongs to this device identity

The verifier uses the CA public key to verify the certificate signature, then uses the device public key inside the certificate to verify the device’s handshake signature.

This is very different from MAC. The server does not need to know the device private key or share one authentication key with all devices. It only needs to trust the CA chain and verify that the device holds the matching private key.

That is why certificate systems scale to large fleets.

Debugging Questions

When seeing a “checksum”, “digest”, “signature”, or “token”, ask:

Does it use a key?
-> no: probably hash

Can the verifier generate the same value?
-> yes: probably MAC

Is it private-key generated and public-key verified?
-> yes: signature

Then ask:

  • does this protect integrity, authentication, or identity accountability
  • where is the key generated and stored
  • should the verifier be able to forge the value
  • is third-party verification needed
  • is replay protection needed
  • are all critical fields covered
  • is the hash or public key itself trusted

Many security designs fail not because the algorithm is weak, but because one mechanism’s promise is used in another scenario.

The Boundary to Remember

Hashes, MACs, and signatures all relate to “data was not changed”, but their commitments differ.

A hash fingerprints data, assuming the fingerprint is trusted. A MAC proves the message came from a shared-key holder. A signature creates a publicly verifiable binding to a private key.

In device security, download checks, message authentication, firmware verification, certificate chains, and audit records need different mechanisms. First decide whether the problem is integrity, shared-key authentication, or public verification, then choose hash, MAC, or signature.