Hashes and Signatures

Module 3 of 7 in the shared chapter Keys, Certificates and Trust, chapter 3 of Securing Salesforce: Identity and Access and chapter 12 of Integration Architect. Each module stands on its own.

The question this module answers: How do you know a message really came from who it says, and that nobody changed it on the way?

Where we left off

In module 2 we found something useful hiding in the two keys. If the town locks a message with its private key, anyone with the public key can open it. That’s not a secret. But only the town holds the private key, so the message must have come from the town.

That’s proof. But there are two problems with doing it that way.

First, the two-key mathematics is slow. Locking a long message with it, every time, is a lot of work.

Second, a lot of messages don’t need to be secret at all. They need to be trusted. Say the town sends the village this: Send the gold by the mountain road. The town doesn’t mind who reads it; the village’s own people will all know soon enough. What matters is that nobody changes it. Because if the bandits stop the rider and change “mountain” to “river”, the village sends its gold straight down the road where the bandits are waiting.

So the question changes. Not “can they read it?” but “has anyone changed it, and did it really come from the town?” To answer it, we need one new tool: the hash.

The hash: a fingerprint of a message

A hash takes a message, any message, and runs it through an algorithm that turns it into a short, fixed-size result. Think of it as the message’s fingerprint.

Here’s the first thing to know. A hash takes no key. It’s the same algorithm for everyone, published, like the ones in module 1. Feed in the same message and you always get the same hash, whether you’re in the village, in the town, or on another continent. It’s completely reproducible.

Here’s the second thing, and it’s the clever part. Change the message even a tiny bit, and the hash comes out completely different. Not a little different. Completely. I call it a magnified effect.

Let’s see it. These are real results from SHA-256, the hash you’ll meet most often today (published by NIST as FIPS 180-4). Its result is 256 bits, written as 64 characters; I’ve shortened them here.

Message	Its SHA-256 hash (shortened)
SEND THE GOLD BY THE MOUNTAIN ROAD	fe6a0afa0c35e939 … 5ca09900
SEND THE GOLD BY THE MOUNTAIN ROAD.	2a645668603a07ad … ccc3fe03cf
SEND THE GOLD BY THE RIVER ROAD	73b635a9bf711a84 … c863b22b

Look at the second line. One full stop added to the end, and nothing in the hash looks anything like the first. So you can’t make a small change and hope for a small, unnoticed difference in the hash.

Three more things make a hash a good fingerprint.

It’s a one-way trip. You can’t go backwards from the hash to the message. A fingerprint tells you whose finger it was; it doesn’t let you rebuild the person.
It’s always the same size. Hash two letters or a whole library, and the SHA-256 hash is 64 characters either way.
Two different messages shouldn’t share a hash. It’s possible, but the odds are so small that it’s practically impossible; more on that below. When the experts find a way to make it happen, the hash is broken.

Any size in, the same size out

Let’s prove that last point. A hash doesn’t care what you feed it: a word, a message, a picture, a whole book, a video. Here are real SHA-256 hashes, in full this time, so you can see they’re all the same length:

What we hashed	Its size	Its SHA-256 hash
The word hi	2 bytes	`8f434346648f6b96df89dda901c5176b10a6d83961dd3c1ac88b59b2dc327aa4`
SEND THE GOLD BY THE MOUNTAIN ROAD	34 bytes	`fe6a0afa0c35e9398c2e1dd5bdbf44d0728d00b2be5894823e97e2bf5ca09900`
A picture: the village diagram from module 1	267 KB	`03b9be1fe54e9444178ea81895e4ac32b7c3ae459e8039015c8056222a70faaa`
A whole book: Pride and Prejudice, from Project Gutenberg	772 KB	`3f6bb9d6f78e0293b56acd4714dd68cb7d6d1d293402031ce9d5a216bcaf9d75`
A video: one of my SteveTechArc videos, From SOQL to SQL: Bridging Salesforce Core & Data 360	102 MB	`69b683711d8d353cab82feb40defce854aea98c5faac3a26e7f92fc64f6619dc`

Two letters, a whole novel, or a video a hundred megabytes long: 64 characters, every time.

One character, a whole new hash

Here’s the part I want you to remember. That full stop at the end of a short message changed everything. It works the same way in a whole book.

Pride and Prejudice starts with one of the best-known lines in English: “It is a truth universally acknowledged, that…” Take out that first comma. One character, out of 772,386. Every other letter in the book stays where it was. Then hash it again:

What we hashed	Its SHA-256 hash
The whole book	`3f6bb9d6f78e0293b56acd4714dd68cb7d6d1d293402031ce9d5a216bcaf9d75`
The whole book, minus one comma	`35ef945c48d020687b19f0c591f66dad933f6afb45e0fb1c90176370e9fe106f`

Nothing carries over. Only 4 of the 64 characters happen to match, about what you’d expect by pure chance. The hash doesn’t tell you where the book changed, or how much. It tells you only that it changed. And that’s exactly what you want from a seal: change one comma in a contract, one number in a payment file, one line in a piece of software, and the hash gives it away.

Can two different things ever have the same hash? Yes, it’s possible. Think about it: a hash is always 64 characters, and there’s no limit to the number of messages, so somewhere out there, two different messages must share a hash. But it’s statistically impossible to find them. SHA-256 has about 1.2 × 10^77 possible results. To find two messages with the same hash by trying, you’d need to hash about 2^128 of them, the same number we met with keys in module 1: at a trillion tries a second, about 10 billion billion years. So in practice, if two hashes match, the messages match. The danger isn’t bad luck. It’s the experts finding a shortcut, and that’s why hashes retire, as you’ll see in a moment.

You’ve already used hashes

You may have used a hash without knowing it. Many software download pages show a long string of letters and numbers next to the download, labelled SHA-256 or checksum. That’s the hash of the file as the publisher released it.

After you download, you hash your copy and compare. On a Mac, in Terminal:

shasum -a 256 pride-and-prejudice.txt
3f6bb9d6f78e0293b56acd4714dd68cb7d6d1d293402031ce9d5a216bcaf9d75  pride-and-prejudice.txt

On Windows, in PowerShell, Get-FileHash pride-and-prejudice.txt does the same; on Linux, sha256sum pride-and-prejudice.txt. If your hash matches the one on the page, your copy is exactly what the publisher released: not damaged, not swapped, not one byte changed. If it doesn’t match, don’t install it.

But notice the weak spot. If the bandits can change the download, maybe they can change the web page that shows the hash, too. A hash on its own proves the file matches that hash. To prove who published the hash, we need the private key. That’s the signature, next.

Hashes retire too

Remember module 1: every algorithm has a date it arrives and, sooner or later, a date it leaves. Hashes are no different. An older hash, SHA-1, was used everywhere for years. Weaknesses were found, and NIST has said it should be phased out by the end of 2030, in favour of the SHA-2 family (which includes SHA-256) and SHA-3. If a system you’re designing still signs with SHA-1, that’s a conversation to have now.

The signature: the hash, locked with the private key

Now put the hash together with module 2’s private key, and you get the most important tool in this chapter.

The town wants to send Send the gold by the mountain road. It doesn’t encrypt the message. It leaves it in clear text, for anyone to read. Instead it does two things:

It hashes the message, and gets the fingerprint.
It locks just that fingerprint with its private key, the gold key.

That locked fingerprint is the digital signature. The town puts it at the bottom of the message and sends both. It’s not like signing a document with a pen, but it is a signature: it says who sent it, and it says what they sent.

And because only the small fingerprint is locked, not the whole message, the slow two-key mathematics only has a little work to do.

Think of an old letter closed with a wax seal pressed with the sender’s own ring. Anyone can read a letter. But if the seal is broken, or it’s the wrong seal, you know something happened to it on the way. A digital signature is that seal, except nobody can copy the ring.

Click to enlarge

Checking the signature

The rider arrives at the village with the message and the signature. Now, what does the village do?

Two things, side by side:

It hashes the message it received, with the same published algorithm, SHA-256.
It opens the signature with the town’s public key, the silver key from the town’s certificate. Inside is the fingerprint the town made.

Then it compares the two. If they match, two things are true at once: the message hasn’t changed since the town signed it, and it was signed with the town’s private key.

Now let’s try it the bandits’ way. They stop the rider and change the message to Send the gold by the river road. The village hashes what arrived and gets 73b635a9…, the river-road fingerprint. It opens the signature and finds fe6a0afa…, the mountain-road fingerprint the town signed. They don’t match. Don’t trust it.

Can the bandits fix that? They’d need to make a new signature for the river road. To do that, they’d have to lock the new fingerprint with the town’s private key, and they don’t have it. If they lock it with their own private key, the town’s public key won’t open it. Either way, the village catches it.

This gives the town one more thing it can’t take back. Since only its private key could have made that signature, the town can’t later say it never sent the message. That’s called non-repudiation: the sender can’t deny it.

Here’s what that looks like for real. We made a 3072-bit key pair for the town, and signed SEND THE GOLD BY THE MOUNTAIN ROAD with the private key, using SHA-256. The signature is 512 characters long; here are the first and last few:

nLPtV9E72nZJG4UhtO7zMmuv1KaxULL7bcxLuqbWd463BSmB … C1zFhVe3Ehvm8oo8URakicnC

It looks like nonsense, and to the bandits it is. Then we checked it with the town’s public key, twice:

The message checked	The result
SEND THE GOLD BY THE MOUNTAIN ROAD	Verified OK
SEND THE GOLD BY THE RIVER ROAD	Verification Failure

Same signature, same public key. One word changed, and the check fails.

So now we have the basic building blocks of trust: encrypt with the public key so only the private key can read it; sign with the private key so anyone can check it with the public key; and the hash that makes the signature small and catches every change.

Signatures are everywhere

Once you know what a signature is, you’ll see them everywhere. Every time, it’s the same idea: hash it, lock the hash with a private key, let anyone check it with the public key.

Software you download and install. Publishers sign their software and updates, and your computer or phone checks that signature before it installs anything. That’s how it knows the update really came from the publisher and wasn’t changed on the way.
Every certificate. Each certificate carries the signature of whoever vouched for it. Module 4 is all about that.
The handshake. When your browser connects to a website, the website signs part of the conversation to prove it holds its private key. Module 5.

And in Salesforce, you’ll see signatures all through this course:

Single sign-on with SAML (the Identity and Access course, chapter 6). The identity provider signs every SAML assertion it sends to Salesforce, and Salesforce checks that signature with the identity provider’s certificate before it lets anyone in. If the signature doesn’t check out, the login fails.
The JWT bearer flow (the Identity and Access course, chapter 11, and the Integration Architect course, chapter 13). A system signs a small token with its private key, and Salesforce checks it with the certificate you uploaded to the External Client App.
The token response itself. When you log in through OAuth and look at what Salesforce sends back, you’ll see a field called signature. Salesforce describes it as a “Base64-encoded HMAC-SHA256 signature signed with the client_secret,” over the ID and the time it was issued, so your app can check the identity URL “hasn’t changed since the server sent it” (OAuth 2.0 Web Server Flow for Web App Integration (opens in a new tab), Salesforce Help, checked 2026-11-07).

That last one isn’t made with a private key. An HMAC is a hash with a shared secret mixed in: the same idea, a fingerprint that catches changes, but both sides hold the same secret, as in module 1. Anyone with the secret can make one, so it proves the message wasn’t changed, but not which of the two sides sent it.

Messages, sign-ins, tokens, software, certificates: if something matters and travels, it’s probably signed. And the moment a system skips checking a signature, everything in this module stops protecting it.

The question that’s left

Look closely at how the village checked the signature. It used the town’s public key, the one in the town’s certificate.

So the signature proves the message matches that key. But whose key is it really? The bandits could make their own key pair, write “town.example” on a certificate with their own public key inside, and sign messages with their own private key. Every check in this module would pass.

Remember the certificate we opened up in module 2. Two rows were waiting: Issuer and Signature. Now you know what the signature row is. Someone else signed the town’s certificate, vouching that this public key really belongs to the town. Who is that someone, and why should the village believe them? That’s module 4, “Hang up and call the bank”.

What an architect decides here

Trust is checked, not assumed. Check every signature, every time.
Check hashes on what you download, and signatures on what you install. If they don’t match, stop.
A signature proves who sent it and that it wasn’t changed, not that it’s secret. If it must also be secret, encrypt it as well.
Know which hash a system signs with. SHA-256 or stronger; plan to retire SHA-1.
A signature is only as good as the public key you check it with. Where that key came from is module 4.

Explore

FIPS 180-4, Secure Hash Standard (SHS) (opens in a new tab) (NIST, August 2015; checked 2026-11-01)
NIST Retires SHA-1 Cryptographic Algorithm (opens in a new tab) (NIST, 2022-12-15; checked 2026-11-01)
Salesforce Help, OAuth 2.0 Web Server Flow for Web App Integration (opens in a new tab), checked 2026-11-07.