RSA, explained without the math

September 2026 · 7 minute read

RSA sits underneath almost every payment you make, and almost every explanation of it starts with modular arithmetic. Let's skip that. You need one picture, a few rules, and a sense of why the clock is now ticking on it.

Start with a mailbox

RSA was created in 1977 by Ron Rivest, Adi Shamir and Leonard Adleman at MIT, which is where the name comes from. It uses two keys that come as a matched pair. One is public, and you can hand it to anyone. The other is private, and it never leaves you.

Think of a mailbox with a slot. Anyone can drop a letter in. Only the person holding the key can open the box and read what's inside.

What makes it hold up is prime numbers. Multiply two huge primes together and you get an even bigger number. That part is easy. Now give someone that big number and ask them to find the two primes you started with. For today's computers, that's practically impossible. That one-way street is the whole lock.

Because the key that locks isn't the key that unlocks, RSA is called asymmetric, or public-key, cryptography.

Which key does what

The mix-up I see most often, even from people who work with this every day, is which key does which job. Here's the whole rule on one screen:

Anyone can lock. Anyone can check. Only you can unlock or sign. In payments, that private key usually lives inside a hardware security module and never comes out.

The three jobs RSA does in payments

1. Authentication: proving who you are

Anything created with the private key can be checked with the public key. So if you can prove you hold the private key, you've proven your identity. That's what happens behind the padlock in your browser at online checkout, when an EMV chip card proves to a terminal that it's genuine, during 3-D Secure, when your phone proves it's a real device as you add a card to a wallet, and between banks using certificates in open banking.

2. Key transport: shipping a secret safely

Think of RSA as a sturdy locked box that only the receiver can open. You don't ship all your valuables in it, because it's slow. You ship one thing: the key to a faster lock that both sides will use from then on. That's how remote key loading gets keys into ATMs and POS terminals, how TR-34 moves keys between devices, and how P2PE terminals get their keys without anyone typing components in by hand.

3. Signing: a seal nobody can fake

A digital signature is a tamper-evident wax seal. Only you can stamp it. Anyone can recognise it. If someone opens or edits the letter, the seal breaks. It proves two things: where the message came from, and that nobody changed it on the way.

How a key pair is made

Four steps, and two keys come out the other side.

1. Step 1Pick two enormous random prime numbers, each around 1,024 bits for a 2048-bit key. Keep them secret. Everything depends on nobody ever learning them.
2. Step 2Multiply them together. The result is the modulus, the big number at the heart of both keys. It's safe to publish, because working backward to the two primes is the hard part.
3. Step 3Choose a public exponent. Almost everyone uses 65537, because it keeps the math fast. There's rarely a reason to change it.
4. Step 4Use the secret primes to work out the matching private exponent. This is the piece only you will ever hold, and it can only be calculated by someone who knows the primes.

Out come two keys: a public one, the modulus plus 65537, which you share with anyone, and a private one, the modulus plus your private exponent, which you protect.

How signing works

Signing happens on the sender's side, and it only ever uses the private key.

1. Step 1Start with the message you want to sign. It could be a payment instruction, an API request, a file, anything.
2. Step 2Run it through a hash function like SHA-256. That boils the whole message down to a short fingerprint. Change a single character and the fingerprint comes out completely different.
3. Step 3Lock that fingerprint with your private key. The result is the digital signature. Only the holder of the private key could have produced it.
4. Step 4Send the message and the signature together. The receiver needs both.

Here's the bit that trips people up: signing is not encryption. The message is still perfectly readable. The signature only proves who sent it and that it hasn't been changed. And because no one else could have produced it, the sender can't later claim they didn't.

How checking works

The receiver has two things, the message and the signature, and checking is a matching game. Two paths, and they should land on the same answer.

1. Step 1Take the message you received and hash it yourself, using the same method the sender used. That gives you the fingerprint the message should have.
2. Step 2Open the signature with the sender's public key. That reveals the fingerprint the sender actually signed.
3. Step 3Compare the two fingerprints.
4. Step 4If they match, the message really came from the sender and nobody changed it. If they don't, something is wrong: the message changed, the signature was forged, or the wrong key was used.

Checking only ever needs the public key. Anyone can verify. Nobody can fake.

One catch that doesn't get enough airtime: a valid signature only means something if you trust the public key behind it. That's what certificates are for. In EMV, the terminal holds the card schemes' root public keys. Those vouch for the bank's key, and the bank's key vouches for the card's key. Follow the chain far enough back and you reach one key that everyone has agreed to trust. That's a root of trust, literally.

If you're building it

You won't write the math yourself. Libraries do that. What you do control is a handful of choices, and each one matters.

Use 2048-bit keys at a minimum, and 3072 or larger for keys that need to live a long time. Leave the public exponent at 65537. Let the operating system or an HSM supply the randomness, because a key is only as strong as the randomness that made it. Hash with SHA-256 or stronger, and never MD5 or SHA-1. For new work, choose PSS padding over the older PKCS#1 v1.5.

Two things that eat afternoons. The verifier has to use exactly the same hash and padding as the signer, or a perfectly genuine signature comes back "invalid," so write your choices down. And with PSS, signing the same message twice gives you two different signatures, both valid. If your tests compare signature bytes, they will fail, and that's by design.

Key sizes, quickly

1024-bit is retired. 2048-bit is today's standard but is being phased out around 2030. 3072-bit is the recommended choice for anything new, and 4096-bit is there for keys that need to last. A bigger key buys you time against today's computers. It does nothing against a quantum one.

The quantum problem

Everything above rests on one assumption: that working backward from the public key to the private key is too hard. Classical computers can't do it. Quantum computers play by different rules, and factoring big numbers happens to be one of the few problems they're built to crush.

This isn't new. In 1994, Peter Shor showed that a quantum computer could factor large numbers efficiently. What's changed is how low the bar has fallen. In 2019, breaking RSA-2048 was estimated to need around 20 million qubits. By 2025, fewer than a million. An early-2026 design put it under 100,000, on paper. Machines that big don't exist yet, and most experts expect a cryptographically relevant one somewhere between the mid-2030s and the 2040s.

That sounds far off until you meet "harvest now, decrypt later." Attackers can record encrypted traffic today and simply wait.

Here's the point I think gets missed in payments: not all RSA carries the same risk. A signature only has to hold up while someone is checking it. A card that authenticated at a terminal this morning can't be un-authenticated in 2038. The danger for signatures starts on the day a quantum computer arrives and forgeries become possible. Key transport is different. A key shipped inside an RSA box today can be opened later by anyone who recorded it, along with everything that key went on to protect. For signatures, the clock starts when quantum arrives. For key transport, it started the day you sent the key.

What replaces RSA

NIST finalised the first post-quantum standards in August 2024. ML-KEM (FIPS 203) takes over key exchange. ML-DSA (FIPS 204) handles signatures, with SLH-DSA (FIPS 205) as a hash-based backup and FN-DSA on the way. For US national security systems, the NSA wants new systems quantum-safe from 2027 and full migration by 2035.

Payments runs on its own standards, though, and so far EMV, ISO and PCI haven't published how post-quantum algorithms should be used in a transaction. EMVCo is still studying it and doesn't expect quantum to threaten EMV before 2040, even as networks experiment with quantum-resistant cards.

So the smart move isn't ripping out RSA tomorrow. It's staying crypto-agile and planning for hybrid, with RSA and post-quantum algorithms running side by side, so you're ready when those standards land.