ECC, explained without the math

September 2026 · 8 minute read

If RSA is the old workhorse of payment security, elliptic curve cryptography is the one quietly taking over. It's in your phone wallet, your browser, your passkeys, and the newest chip cards. It does the same kind of job as RSA with keys a fraction of the size. Here's how it works, without a single equation.

Start with a game of hops

ECC was proposed in 1985 by two mathematicians working separately, Neal Koblitz and Victor Miller. It took about twenty years for the industry to trust it, and now it's everywhere.

Picture a curved line drawn on a board, and a marked starting point on it that everyone agrees on. There's a simple rule for "hopping" from one point on the curve to another. Each hop lands somewhere that looks completely random.

Now you secretly pick a number, say a few trillion trillion, and hop that many times. You tell the world where you started and where you landed. Anyone can check that your landing spot is on the curve. Nobody can work out how many hops it took. Counting forward is quick. Counting backward is practically impossible.

That's the whole trick. The number of hops is your private key. The landing point is your public key. RSA leans on how hard it is to split a big number into its primes. ECC leans on how hard it is to count the hops.

Why payments likes it: small keys, same strength

A 256-bit ECC key gives roughly the same protection as a 3072-bit RSA key. That's twelve times smaller for the same strength, and the gap widens as you go up.

Smaller keys mean smaller signatures, 64 bytes instead of 384, and much faster key generation and signing. That matters on a chip card with a tiny processor, a phone that has to answer a tap in a fraction of a second, and an HSM signing thousands of transactions a second.

Which key does what

This is where ECC differs from RSA, and it catches people out. ECC doesn't lock messages the way RSA does. It does two jobs: signing, and agreeing on a shared secret.

So when you need to send something secret with ECC, you first agree on a key with the other side, then encrypt with a fast cipher like AES using that key. Apple Pay's payment token works exactly this way.

Where ECC shows up in payments

Online checkout. When your browser connects to a checkout page over modern TLS, the two sides almost always agree on a session key using ECC, then prove the server's identity with a signature.

Phone wallets. Apple Pay and Google Pay rely on ECC keys held in the phone's secure hardware. Apple Pay's encrypted payment token is opened by the merchant or processor using ECC key agreement.

Passkeys and cardholder authentication. Passkeys, which are increasingly used to confirm online card payments, almost always use ECDSA on the P-256 curve.

Open banking. Banks and fintechs commonly sign API messages with ES256, which is ECDSA on P-256.

Chip cards. Classic EMV cards use RSA. EMVCo's newer contactless kernel, C-8, brings ECC to card authentication, with smaller keys that suit fast taps.

How a key pair is made

It's simpler than RSA. There are no primes to hunt for, which is a big part of why it's fast.

1. Step 1Agree on which curve to use and its standard starting point. These are published and everyone uses the same ones. P-256 is the most common in payments.
2. Step 2Pick a random secret number. This is your private key. Its quality depends entirely on the randomness behind it, so let the operating system or an HSM generate it.
3. Step 3Hop that many times from the starting point. There are shortcuts that make this fast even for enormous numbers.
4. Step 4The point where you land is your public key. Publish it. Nobody can work back from it to your number.

How signing works

ECC signing is called ECDSA. It looks a lot like RSA signing with one crucial extra ingredient: a fresh random number for every signature.

1. Step 1Run the message through a hash function to get its fingerprint, exactly as with RSA.
2. Step 2Pick a brand-new random number, used once and then thrown away. It's called a nonce.
3. Step 3Combine the fingerprint, the nonce and your private key. Out come two numbers, r and s. Together they're the signature, 64 bytes on P-256.
4. Step 4Send the message and the signature together. As with RSA, signing isn't encryption, and the message stays readable.

Step 2 is where ECC bites. Use the same nonce twice, or a predictable one, and anyone holding the two signatures can calculate your private key. This isn't theoretical. In 2010, Sony signed PlayStation 3 software using the same "random" number every time, and the private key fell out with some school-level algebra. That's why modern libraries generate the nonce from the message and the key itself (deterministic ECDSA), and why Ed25519 was designed so this mistake can't happen.

How checking works

The receiver has the message, the signature and your public key. Checking only ever uses public information.

1. Step 1Hash the message you received, using the same hash the signer used.
2. Step 2Feed the fingerprint, the signature and the sender's public key into the verification math. It lands you on a point on the curve.
3. Step 3Compare that point with the r part of the signature.
4. Step 4If they line up, the message is genuine and untouched. If they don't, reject it.

The same catch applies as with RSA: a valid signature only means something if you trust the public key, which is what certificates are for.

How two sides agree on a secret

This is ECC's other job, called ECDH, and it's the one RSA doesn't do natively. Think of mixing paint. Each side starts with its own secret colour, mixes it with the other side's public colour, and both end up with the same final shade. Anyone watching sees only the public colours, and can't unmix them.

1. Step 1Each side makes its own key pair and sends the other side its public key. Anyone can see these.
2. Step 2Each side combines its own private key with the other side's public key.
3. Step 3Both land on exactly the same shared secret, even though it never travelled over the network.
4. Step 4Run that secret through a key derivation step to get an AES key, and use it to encrypt the actual data.

In TLS, both sides create brand-new key pairs for every session and throw them away afterward. That means even if a server's long-term key leaks years later, recorded sessions stay locked. It's a big reason modern TLS moved to ECC.

If you're building it

Use P-256 unless you have a reason not to. It's supported by every HSM, every payment scheme and every FIPS-validated library. Ed25519 is a strong choice where it's supported, because it's fast and hard to misuse.

Never generate the signing nonce yourself. Use a library that does deterministic ECDSA, or use Ed25519. Pair the hash with the curve: SHA-256 with P-256, SHA-384 with P-384.

When you receive someone's public key, check that it really is a point on the curve. Skipping this check has led to real attacks where a bad key tricks your side into leaking information.

And the one that eats afternoons: ECDSA signatures come in two formats. Some libraries give you a compact 64-byte form, and others wrap the same numbers in a DER structure of about 70 to 72 bytes. JWTs and open banking use the compact form. If a perfectly good signature keeps failing, check the format before you check anything else.

Key sizes, quickly

A 256-bit curve matches RSA-3072. A 384-bit curve matches roughly RSA-7680. A 521-bit curve matches roughly RSA-15360. In practice, P-256 covers most payment use today, and P-384 is the choice for long-lived keys and government work.

The quantum problem

ECC falls to Shor's algorithm too, exactly like RSA. Counting the hops backward is precisely the kind of problem a large quantum computer can solve.

Don't assume ECC buys you extra time here. Its small keys, a strength today, also give a quantum computer less to chew through, and many researchers expect ECC to fall no later than RSA, possibly sooner.

Harvest now, decrypt later hits ECDH hardest, because that's the part protecting today's encrypted traffic. The good news is that this is also where the fix is furthest along. Major browsers and Cloudflare already use a hybrid called X25519MLKEM768, which pairs classic ECC key agreement with the new post-quantum ML-KEM. An attacker has to break both. ML-DSA and SLH-DSA are the post-quantum replacements for ECDSA signatures.

A quick note on ECC variants

"ECC" isn't one thing. It's a family of curves, each paired with a few algorithms: ECDSA and EdDSA for signing, ECDH and X25519 for key agreement. Here are the ones you'll actually meet.

Why so many? Partly speed, partly politics, and partly trust. The NIST curves were generated from seed values that were never fully explained, which made some cryptographers uneasy. There's no known weakness, but it's why Curve25519, whose every design choice is documented, won so many fans. For payments, the practical answer is simple: use what your HSM and your scheme support, and today that's the NIST curves.