May 09, 2025·8 min
Ron Rivest and Practical Cryptography: Why RSA Won
How Ron Rivest helped shape practical cryptography: RSA, signatures, and the security engineering choices that made secure commerce and HTTPS common.
How Ron Rivest helped shape practical cryptography: RSA, signatures, and the security engineering choices that made secure commerce and HTTPS common.
Ron Rivest is one of those names you rarely hear outside security circles, yet his work quietly shapes what “normal” safety feels like online. If you’ve ever logged into a bank, bought something with a card, or trusted that a website is really the one you meant to visit, you’ve benefited from a style of thinking Rivest helped popularize: cryptography that works in the real world, not just on paper.
Secure communication is hard when millions of strangers need to interact. It’s not just about keeping messages private—it’s also about proving identity, preventing tampering, and making sure payments can’t be forged or quietly rerouted.
In a small group, you can share a secret code ahead of time. On the internet, that approach collapses: you can’t pre-share a secret with every site, store, and service you might use.
Rivest’s influence is tied to a bigger idea: security becomes widespread only when it becomes the default. That takes three ingredients working together:
This is a high-level, non-mathematical tour of how RSA fit into a practical security stack—encryption, signatures, certificates, and HTTPS—and why that stack made secure commerce and communication routine rather than exceptional.
Before RSA, most secure communication worked like a shared diary lock: both people needed the same secret key to lock and unlock messages. This is symmetric cryptography—fast and effective, but it assumes you already have a safe way to share that secret.
Public-key cryptography flips the setup. You publish one key (public) that anyone can use to protect a message for you, and you keep the other key (private) that only you can use to open it. The math is clever, but the reason it mattered is simple: it changed how secrets get distributed.
Imagine an online store with a million customers. With symmetric keys, the store would need a separate shared secret with each customer.
That creates messy questions:
When communication is one-to-one and offline, you might exchange a secret in person or via a trusted courier. On the open internet, that approach breaks down.
Think of sending a valuable item through the mail. With symmetric keys, you and the recipient must somehow share the same physical key first.
With public keys, the recipient can mail you an open padlock (their public key). You put the item in a box, snap on that padlock, and send it back. Anyone can hold the padlock, but only the recipient has the key that opens it (their private key).
That’s what the internet needed: a way to exchange secrets safely with strangers, at scale, without a prearranged shared password.
Public-key cryptography didn’t start with RSA. The big conceptual shift arrived in 1976, when Whitfield Diffie and Martin Hellman described how two people could communicate securely without first sharing a secret in person. That idea—separating “public” information from “private” secrets—set the direction for everything that followed.
A year later (1977), Ron Rivest, Adi Shamir, and Leonard Adleman introduced RSA, and it quickly became the public-key system people could actually deploy. Not because it was the only clever idea, but because it fit the messy needs of real systems: straightforward to implement, adaptable to many products, and easy to standardize.
RSA made two critical capabilities widely usable:
Those two features sound symmetric, but they solve different problems. Encryption protects confidentiality. Signatures protect authenticity and integrity—proof that a message or software update really came from who it claims.
RSA’s power wasn’t only academic. It was implementable with the computing resources of the time, and it fit into products as a component rather than a research prototype.
Just as important, RSA was standardizable and interoperable. As common formats and APIs emerged (think shared conventions for key sizes, padding, and certificate handling), different vendors’ systems could work together.
That practicality—more than any single technical detail—helped RSA become a default building block for secure communication and secure commerce.
RSA encryption is, at its core, a way to keep a message confidential when you only know the recipient’s public key. You can publish that public key widely, and anyone can use it to encrypt data that only the matching private key can decrypt.
That solves a practical problem: you don’t need a secret meeting or a pre-shared password before you can start protecting information.
If RSA can encrypt data, why not use it for everything—emails, photos, database exports? Because RSA is computationally expensive and has strict size limits: you can only encrypt data up to a certain length (roughly tied to the key size) and doing it repeatedly is slow compared to modern symmetric algorithms.
That reality pushed one of the most important patterns in applied cryptography: hybrid encryption.
In a hybrid design, RSA protects a small secret, and a faster symmetric cipher protects the bulk data:
This design choice is mostly about performance and practicality: symmetric encryption is built for speed on large data, while public‑key encryption is built for safe key exchange.
Many modern systems prefer different key‑exchange methods (notably ephemeral Diffie‑Hellman variants in TLS) for stronger forward secrecy and better performance characteristics.
But RSA’s “public key to protect a session secret, symmetric crypto for the payload” model set the template that secure communication still follows.
A digital signature is the online equivalent of sealing a document with a tamper-evident stamp and an ID check at the same time. If even one character in the signed message changes, the signature stops matching. And if the signature verifies with the signer’s public key, you have strong evidence about who approved it.
It’s easy to mix these up because they often travel together, but they solve different problems:
You can sign a message that everyone can read (like a public announcement). You can also encrypt something without signing it (private, but you don’t know who really sent it). Many real systems do both.
Once RSA made public-key signatures practical, businesses could move trust from phone calls and paper to verifiable data:
People often describe signatures as providing non-repudiation—preventing a signer from credibly denying they signed. In practice, it’s a goal, not a guarantee. Key theft, shared accounts, weak device security, or unclear policies can muddy attribution.
Digital signatures are powerful evidence, but real-world accountability also needs good key management, logging, and procedures.
Public-key cryptography sounds simple: publish a public key, keep a private key secret. The messy part is answering one question reliably at internet scale: whose key is this?
If an attacker can swap in their own key, encryption and signatures still “work”—just for the wrong person.
A TLS certificate is basically an ID card for a website. It binds a domain name (like example.com) to a public key, plus metadata such as the organization (for some certificate types) and an expiration date.
When your browser connects over HTTPS, the server presents this certificate so the browser can verify it’s talking to the right domain before establishing encrypted communication.
Browsers don’t “trust the internet.” They trust a curated set of Certificate Authorities (CAs) whose root certificates are preinstalled in the operating system or browser.
Most websites use a chain: a leaf certificate (your site) is signed by an intermediate CA, which is signed by a trusted root CA. If each signature checks out and the domain matches, the browser accepts the public key as belonging to that site.
Certificates expire, typically in months, so teams must renew and deploy them regularly—often automated.
Revocation is the emergency brake: if a private key leaks or a certificate was issued incorrectly, it can be revoked. In reality, revocation is imperfect—online checks can fail, add latency, or be skipped—so shorter lifetimes and automation have become key operational strategies.
PKI scales trust, but it centralizes it. If a CA makes a mistake (mis-issuance) or is compromised, attackers may obtain valid-looking certificates.
PKI also adds operational complexity: certificate inventory, renewal pipelines, key protection, and incident response. It’s not glamorous—but it’s what makes public keys usable by ordinary people and browsers.
RSA proved that public-key cryptography could work in real systems. TLS (the protocol behind HTTPS) is where that idea became a daily habit for billions of people—mostly without them noticing.
When your browser shows an HTTPS connection, TLS is aiming for three things:
Historically, RSA often played a direct role in step 4 (RSA key transport). Modern TLS usually uses ephemeral Diffie–Hellman (ECDHE) instead, which enables forward secrecy: even if a server’s long-term key is stolen later, past captured traffic is still unreadable.
TLS succeeded because it made security operationally convenient: automatic negotiation, defaults baked into browsers and servers, and visible cues (the lock icon, warnings) that nudged behavior. That “secure by default” experience mattered as much as any algorithmic advance—and it turned cryptography from a specialist tool into ordinary infrastructure.
RSA (and the cryptography built on top of it) can be mathematically sound and still fail in practice. The difference is often boring but decisive: how you generate, store, use, rotate, and recover the keys.
Strong crypto protects data; strong key handling protects the crypto.
If an attacker steals your private key, it doesn’t matter that RSA is well-studied. They can decrypt what you encrypted, impersonate your servers, or sign malware “as you.”
Security engineering treats keys as high-value assets with strict controls—much like cash in a vault rather than notes on a desk.
Key management isn’t one task—it’s a lifecycle:
To reduce key exposure, organizations use hardware-backed protections. Hardware Security Modules (HSMs) can generate and use keys inside a protected device so the private key material is harder to export. Secure enclaves offer similar isolation within modern CPUs, helping keep key operations separated from the rest of the system.
These tools don’t replace good processes—they help enforce them.
Many real breaches are “crypto-adjacent” mistakes:
RSA enabled secure communication at scale, but security engineering made it survivable in the messy world where keys live.
Even teams moving fast—especially those generating and deploying apps quickly—run into the same fundamentals: TLS termination, certificate renewal, secrets handling, and least-privilege access.
For example, platforms like Koder.ai (a vibe-coding workflow that generates and ships web, backend, and mobile apps from chat) can drastically reduce development time, but they don’t remove the need for operational security choices. The win is making secure defaults and repeatable deployment practices part of the pipeline—so speed doesn’t translate into “someone copied a private key into a ticket.”
Threat modeling is simply answering: who might attack us, what do they want, and what can they realistically do?
Cryptography didn’t become practical because it was mathematically elegant; it won because engineers learned to match defenses to the most likely failures.
A passive eavesdropper just listens. Think of someone on public Wi‑Fi capturing traffic. If your threat is passive, encryption that prevents reading the data (plus good key sizes) goes a long way.
An active attacker changes the game. They can:
RSA-era systems quickly learned that confidentiality alone wasn’t enough; you also need authentication and integrity (digital signatures, certificate validation, nonces, and sequence numbers).
Good threat models lead to concrete deployment decisions:
The lesson is consistent: define the attacker, then choose controls that fail safely—because the real world is full of misconfigurations, stolen keys, and surprises.
Online commerce isn’t one secure conversation—it’s a chain of handoffs. A typical card payment starts in a browser or mobile app, moves through the merchant’s servers, then to a payment gateway/processor, into the card network, and finally to the issuing bank that approves or declines the charge.
Each hop crosses organizational boundaries, so “security” has to work between strangers who can’t share a single private network.
At the customer edge, cryptography mostly protects transport and server identity. HTTPS (TLS) encrypts the checkout session so card data and addresses aren’t exposed on the wire, and certificates help the browser verify it’s talking to the merchant (not a look‑alike site).
Inside the payment chain, crypto is also used for authentication and integrity between services. Gateways and merchants often sign requests (or use mutual TLS) so that an API call can be proven to have come from an authorized party and not been altered in transit.
Finally, many systems use tokenization: the merchant stores a token instead of raw card numbers. Crypto helps protect the mapping and limits what leaked databases can reveal.
Even perfect encryption can’t determine whether the buyer is legitimate, whether a shipping address is suspicious, or whether a cardholder will later dispute the transaction.
Fraud detection, chargebacks, and identity proofing rely on operational controls, risk scoring, customer support workflows, and legal rules—not just math.
A customer checks out on a site over HTTPS, submitting payment details to the merchant. The merchant then calls the gateway’s API.
That back‑office request is authenticated (for example, with a signature made using the merchant’s private key, verified with the corresponding public key) and sent over TLS. If an attacker tampers with the amount or destination account, signature verification fails—even if the message was replayed or routed through untrusted networks.
This is why RSA-era ideas mattered for commerce: they enabled encryption, signatures, and manageable trust relationships across many independent systems—exactly what payments require.
Most security incidents involving RSA, TLS, or certificates don’t happen because the math “broke.” They happen because real systems are glued together from libraries, configurations, and operational habits—and that’s where sharp edges live.
A few missteps show up again and again:
These failures often look boring—until they become an outage, a breach, or both.
Building custom encryption or signature code is tempting: it feels faster than learning standards and picking libraries. But security isn’t just an algorithm; it’s randomness, encoding, padding, key storage, error handling, side-channel resistance, and safe upgrades.
Common “homebrew” failures include predictable random numbers, insecure modes, or subtle verification bugs (“accepting” a signature or certificate that should be rejected).
The safer move is simple: use well-reviewed libraries and standard protocols, and keep them updated.
Start with defaults that reduce human effort:
If you need a reference baseline, link your internal runbook to a single “known-good” config page (for example, /security/tls-standards).
Watch for:
The punchline: practical cryptography succeeds when operations make the secure path the easy path.
RSA’s biggest win wasn’t only mathematical—it was architectural. It popularized a repeatable pattern that still underpins secure services: public keys that can be shared, certificates that bind keys to real identities, and standard protocols that make those pieces interoperable across vendors and continents.
The practical recipe that emerged looks like this:
That combination made security deployable at scale. It let browsers talk to servers, payment gateways talk to merchants, and internal services talk to each other—without every team inventing its own scheme.
Many deployments have shifted away from RSA for key exchange and, increasingly, for signatures. You’ll see ECDHE for forward secrecy and EdDSA/ECDSA for signing in newer systems.
The point isn’t that RSA is “the answer” forever; it’s that RSA proved a crucial idea: standardized primitives plus disciplined key management beat clever one-off designs.
So even as algorithms change, the essentials stay:
Default security is not a checkbox—it’s an operating mode:
When building or buying secure communication and payment systems, prioritize:
RSA’s legacy is that security became something teams could adopt by default—through interoperable standards—rather than reinvent with every product launch.
RSA made public-key cryptography practical to deploy: anyone could use a public key to encrypt data for you, and you could use a private key to decrypt it. Just as importantly, RSA supported digital signatures, which let others verify that data really came from you and wasn’t altered.
That combination (encryption + signatures) fit real products and could be standardized, which helped it spread.
Symmetric crypto is fast, but it requires both parties to already share the same secret key.
At internet scale, that turns into hard problems:
Public-key crypto (including RSA) changed the distribution problem by letting people publish a public key openly.
Hybrid encryption is the practical pattern where public-key crypto protects a small secret, and symmetric crypto protects the bulk data.
Typical flow:
This exists because RSA is slower and has size limits, while symmetric ciphers are built for large data.
Encryption answers: “Who can read this?”
Digital signatures answer: “Who approved this, and was it modified?”
Practically:
A TLS certificate binds a domain name (like example.com) to a public key. It lets your browser verify that the server you connected to is presenting a key that is authorized for that domain.
Without certificates, an attacker could substitute their own public key during connection setup and still make encryption “work”—but with the wrong party.
Browsers and operating systems come with a set of trusted root Certificate Authorities (CAs). Most sites use a chain:
During an HTTPS connection, the browser verifies:
In modern TLS, key agreement is usually done with ephemeral Diffie–Hellman (ECDHE) instead of RSA key transport.
Main reason: forward secrecy.
RSA can still appear in TLS via certificates/signatures, but the handshake has largely moved to ECDHE for key agreement.
Common operational failures include:
The math may be sound, but real systems fail due to key handling, configuration, and patch hygiene.
Key management covers the lifecycle of cryptographic keys:
If an attacker steals a private key, they can decrypt protected data (in some designs) or impersonate services and sign malicious content—so operational controls around keys are as important as the algorithm.
Use crypto to secure the connections and messages between parties that don’t share a private network:
Crypto doesn’t solve fraud or disputes by itself—those require risk controls and processes—but it makes the payment pipeline much harder to intercept or tamper with.
If those checks pass, the browser accepts the site’s public key as belonging to that domain.