Keys and Ciphers

Image generated with AI

Module 1 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: If someone can read every message you send, how do you keep the message secret?

Every identity mechanism, and every integration that has to trust another system, comes down to one question: why should one system believe another? Single sign-on, OAuth, certificates, two-way TLS. Before we get to any of them, we need the plumbing underneath, and that plumbing is encryption. I’m going to build it up from a little village, a rider and some bandits, because once you see the problem the way the village saw it, the rest of this chapter falls into place.

The bandits read everything

Picture a small village. Every week the village sends a rider to the town with a message, and some messages matter. This week’s says: Gold leaves Friday by the mountain road. The village is sending its gold to the town, and the town needs to know when it’s coming and which way. Anyone else who learns it knows exactly where to wait.

Between the village and the town is a long road, and on that road are the bandits. You can call them thieves or hackers. Whatever you call them, here’s what they do. They stop the rider. They search him. They find the message and read it. They make a copy. Then they let him ride on.

The town gets its message on time and never knows anyone else read it. The bandits now know when the gold travels, and which road it takes. And they keep the copy, along with every other message they’ve ever taken from a rider on that road.

So here’s my question to you. If you know every message is going to be read, what do you do?

You can’t stop the bandits from reading it. You make sure that what they read means nothing to them.

That road is the network. Every message between your browser and Salesforce, or between Salesforce and another system, crosses networks other people own. Anyone along the way with the right tools can watch the traffic go past and copy it. That’s called packet sniffing, and it’s the bandits’ search, done by a computer, at the speed of the network. A network card normally picks up only the packets addressed to it; a packet sniffer is one programmed to catch every packet that goes past, like a vacuum cleaner. Architects assume from the start that every message can be read, and kept.

The cipher wheel

One of the earliest answers to this problem goes back thousands of years: the cipher wheel. Two rings of letters, one inside the other. You turn the inner ring by some number of letters, the offset, and now every letter on the outer ring lines up with a different letter on the inner ring.

Click to enlarge

Turn the inner ring by three: A lines up with D.

The village and the town agree on the wheel and the offset ahead of time. That offset is the secret both of them hold. It’s the simplest possible key. The village takes the clear text, the message anyone can read, runs it through the wheel, and gets encrypted text. That’s what the rider carries. At the other end, the town has the same wheel and the same key, turns it back, and gets the clear text again.

With an offset of 3, A becomes D, B becomes E, and so on:

Clear text	GOLD LEAVES FRIDAY BY THE MOUNTAIN ROAD
Encrypted text	JROG OHDYHV IULGDB EB WKH PRXQWDLQ URDG

The bandits stop the rider, search him and copy the message, just as before. Only now they get JROG OHDYHV IULGDB EB WKH PRXQWDLQ URDG. It means nothing to them. The rider rides on, and the town reads Gold leaves Friday by the mountain road.

Click to enlarge

Why a fixed wheel fails

Now the village sends its weekly message, and the next one, and the next one, all with the same wheel and the same key. Every message, the same key. Can you tell me a problem with that?

There are three, and the bandits have time for all of them.

First, try them all. There are only 25 offsets. A bandit with a pencil and a quiet afternoon tries every one, and one of them reads like a message.

Second, count the letters. In English, some letters turn up far more often than others: E most of all, then T, A, O and I. Collect enough encrypted messages, find the letter that turns up most often, and you’ve probably found the E. Now you know the offset. Every language has its own pattern of common letters, so this works whatever language the village writes in.

Here’s what that looks like. We counted the letters in three well-known English books, more than 1.3 million letters, and here are the six most common, with the letter each one becomes on our wheel turned by three:

Click to enlarge

So the bandits count the letters in their pile. H turns up far more than any other letter. H is three letters after E. The offset is three, and every message in the pile opens.

Beyond the wheel: mix up the whole alphabet. The wheel keeps the alphabet in order and only turns it, so once you know where one letter went, you know where they all went. What if the village didn’t use a wheel at all? Mix up the whole alphabet instead: A becomes Q, B becomes M, C becomes X, with no pattern from one letter to the next. Now there’s no offset to find, and trying every key is hopeless: there are about 4 × 10^26 ways to mix up 26 letters. Leave out the spaces between words too, so the bandits can’t spot the short words. It still falls to the letter count. Each letter still becomes the same other letter every time, so its count comes along with it. The most common letter in the pile is probably E. The next few are probably T, A, O and I. From there, the bandits fill in the rest a few letters at a time, the way you’d solve a puzzle. So the real weakness was never the wheel’s turn. It’s that the pattern of the language shows through. A strong algorithm has to hide that pattern, not just swap one letter for another.

Third, once it’s cracked, they can read everything. Remember the copies. The bandits didn’t just read this week’s message; they kept every message they ever took. The day they crack the key, they go back through the pile and read all of them. Every message, back in time.

That third one is the one to remember, because it’s still true today. Someone can record encrypted traffic now, keep it for years, and read it the day the protection is broken. So the question isn’t only “can they read it today?” It’s “how long does this message need to stay secret?”

A stronger algorithm, in the open

So the first thing the village needs is a stronger way to scramble the message. This is where the experts in cryptography came along, the smart PhDs. They replaced the wheel with an algorithm: a long, careful mathematical recipe for scrambling a message, far stronger than turning a ring of letters. Picture the wheel turning into a set of gears.

And then they did something that surprises people: they published the algorithm. Instead of hiding the recipe, they put it out in the open, where every other expert could attack it. That’s what you want. An algorithm that has survived years of the world’s best people trying to break it is one you can trust. A secret one has only been tested by the people who made it.

Algorithms don’t last forever. Computers get faster, and the experts find weaknesses nobody saw at first. When that happens, the algorithm has to be replaced, and every system that uses it has to change. It has happened before. An older algorithm, DES, was a standard for years; the US standards body NIST withdrew it in 2005 because it no longer gave the protection needed. Here are a few you’ll hear about, past and current:

Algorithm	Its story	Where it stands
DES	A US standard from the 1970s, with a short key	Withdrawn by NIST in 2005
Triple DES	DES run three times, to buy time	Not allowed by NIST for encrypting after December 31, 2023; only for decrypting old data
RC4	Once used widely on the web	Banned from the web’s secure connections in 2015 (RFC 7465)
AES	The Advanced Encryption Standard, NIST, 2001	Current: the one you’ll meet most
ChaCha20	Published by the IETF in 2018 (RFC 8439)	Current: one of the choices in today’s web handshake (TLS 1.3)

Notice the pattern: every algorithm has a date it arrived and, sooner or later, a date it leaves. There are others, for different jobs, and you’ll meet some of them later in this chapter. You’ll also see the same retiring of the old and moving to the new when we get to the handshake that protects the web.

The key, and the two attacks

If the algorithm is public, what’s secret? What does an algorithm need, besides the message, to encrypt something?

A key. You feed the algorithm two things: the clear text and the key. Out comes the encrypted text. Without the key, the encrypted text is useless, even to someone who knows exactly how the algorithm works. Here, the village and the town use the same key to lock and to unlock. That’s called symmetric encryption: one key, both directions. Hold on to that word. The next module needs it.

So the bandits go after the key. What do we call it when a computer tries every word in the dictionary, then the same words with numbers and birth dates added? A dictionary attack. And when it simply tries every possible combination, smallest first, growing bigger and bigger? A brute force attack.

A dictionary attack is why a key must never be a word. Brute force is why a key must be long. Let’s do the math.

Say each character of a key can be a lowercase letter (26), an uppercase letter (another 26), a digit (10, so 62 so far) or one of about 10 symbols. That’s about 72 choices for every position, and every extra character multiplies the possibilities by 72 again.

Now give the bandits a fast computer. I’ll assume, just for this example, that it can try a trillion keys a second. That’s an assumption to make the numbers concrete, not a measured speed.

Key	Possible keys	Time to try them all, at a trillion a second
8 characters	about 7.2 × 10^14	about 12 minutes
12 characters	about 1.9 × 10^22	about 600 years
A 128-bit AES key	about 3.4 × 10^38	about 10^19 years

Four more characters take you from a coffee break to six centuries. That’s what length does. And a real AES key isn’t something a person types at all. It’s 128 bits chosen at random, which puts it far beyond brute force. So the longer the key, the better, and a strong algorithm with a long, random key is something the bandits can’t get through.

A quick look ahead, because you’ll hear the question: what about quantum computers? Is anything unbreakable? Only one method is mathematically proven unbreakable, the one-time pad: a truly random key as long as the message, used once and then destroyed. And look at the catch. A key as long as every message, delivered safely to the other side every time. That’s the key problem, as big as it gets. For everything else, “strong” means “no known way to break it in any useful time”. Experts expect large quantum computers to weaken long keys like AES only a little; NIST notes that this kind of quantum attack likely gives no real advantage in practice, and it hasn’t retired AES-128. The real quantum danger is to the two-key algorithms in the next module. NIST published the first standards built to withstand quantum computers in 2024 and has set out a plan to move to them. Every algorithm has a date it leaves, and for some, that date is now on the calendar.

Which means they stop attacking the message and start looking for the key.

The problem that’s left

Look at where we are. Every message can be read, so every message is encrypted. The algorithm is strong, public and tested. The key is long and random. The bandits can copy the encrypted text all day long and learn nothing.

But the town needs the key to read the message. The village has it. The town doesn’t. And the only road between them belongs to the bandits. If the rider carries the key, the bandits copy the key, and then they can read everything, including every message in their pile.

We’ve shifted the problem from encryption to key management. Somehow both sides have to have the key, and nobody else can.

And it isn’t only the first key. Remember the bandits’ pile of copies. If the village uses one key for every message, for years, then the day that key is cracked or stolen, every message in the pile can be read. So the village should rotate its keys: make a new key every so often, so a cracked key opens only the messages sent with it, and not every message ever sent. But think about what rotating means. Every new key has to get from the village to the town, down the same road, past the same bandits. Each rotation is the key management problem all over again.

The same goes for using one key for everything. One key for the gold, the grain and the letters home means one cracked key opens all of them. Separate keys for separate jobs, each replaced on a schedule, keep a single loss small. You’ll see this idea again and again in cryptography, and in how Salesforce handles its own keys and certificates later in this course.

For a long time the answer was to meet in person, or send someone you trusted. That doesn’t work for a browser opening a website it has never seen before, or for Salesforce calling a system on the other side of the world for the first time. The next module is how the experts solved it: not one key, but two.

What an architect decides here

• Assume every message can be read, and kept. Encrypt it, and protect it for as long as it must stay secret, not just for the moment it crosses the network.
• Use a published, tested algorithm, and be ready to replace it. Never invent your own. Algorithms get retired, so know which ones your systems use.
• The longer the key, the better. Long and random, never a word.
• Rotate keys, and don’t use one key for everything. A cracked key should open as little as possible, for as short a time as possible.
• The key is the secret, so where keys live is a design decision. Who holds them, where they’re stored, how they reach the other side and how they’re replaced. The rest of this chapter, and the chapters on apps and tokens, build on this.

Explore

• FIPS 197, Advanced Encryption Standard (AES) (opens in a new tab) (NIST, published 2001-11-26, updated 2023-05-09; checked 2026-10-31)
• NIST to Withdraw Special Publication 800-67 Revision 2 (opens in a new tab) (NIST, 2023-06-29: Triple DES; checked 2026-11-07)
• RFC 7465: Prohibiting RC4 Cipher Suites (opens in a new tab) (IETF, February 2015; checked 2026-11-01)
• RFC 8439: ChaCha20 and Poly1305 for IETF Protocols (opens in a new tab) (IETF, June 2018; checked 2026-11-01)
• NIST Releases First 3 Finalized Post-Quantum Encryption Standards (opens in a new tab) (NIST, 2024-08-13; checked 2026-11-01)
• Post-Quantum Cryptography: FAQs (opens in a new tab) (NIST; checked 2026-11-01)
• NIST Withdraws Outdated Data Encryption Standard (opens in a new tab) (NIST, 2005-06-02; checked 2026-10-31)