Playing with cryptography
Maybe Mental Poker is a good way to start this blog. It's a paper that changed the way I see things.
The paper appeared in 1978. The Cold War was on and the U.S. still classified cryptography as "munitions." Shamir, Rivest, and Adleman were perfecting public-key cryptography. They'd later turn their discovery into RSA Data Security Ltd to put those keys in everyone's hands. The NSA pressured them to stop (though not every US agency agreed) and if the RSA trio hadn't been so defiant, only governments would have encryption today. No HTTPS, no online shopping, no private messaging. The internet would be just surveillance and ads.
So here they were, the godfathers of cryptography, with a dorky puzzle about card games and MODEMS?
Can two potentially dishonest players play a fair game of poker without using any cards—for example, over the phone? This paper provides the following answers:
1 No. (Rigorous mathematical proof supplied.)
2 Yes. (Correct and complete protocol given.)
And then, with a straight face:
You might find it an interesting challenge to attempt to find, on your own, a method for playing Mental Poker, before reading on.
I found the paper last year. I was halfway through a course on the math behind zero-knowledge proofs. I’d implemented Diffie–Hellman. I knew the machinery of public-key systems. Still, I thought, "They're talking to the masters, not someone like me."
The surprise was that their solution hinged on a basic primitive I already knew as a beginner—just used in a way I had never considered.
It got me thinking about everything else.
Why do cryptographic primitives get boxed in?
Key pairs become “encrypt messages.”
HD keys become “wallet accounts.”
Commit–reveal is some toy protocol from the 80s that we say is for auctions, but hardly gets used outside of classrooms.
It's funny how fast we turn a mathematical structure into a product category.
My friend Ronan is a regular hackathon winner. Whatever framework comes out, he dives in and learns it. But when he sits down to build his games, he keeps coming back to a simple commit-reveal.
When he asks, “Why do I need anything else?” he’s not being dismissive; he’s noticing that we're not using the simpler things we already have.
The story with hashes shows the same thing. They were first used in databases for storage integrity. Then someone realized you could use them as proof-of-work and build distributed ledgers. Suddenly, data distribution can depend on verifiable math instead of trusting institutions. Blockchains.
Blockchains didn't require new cryptography. They required seeing hashes for what they really do.
Long division as cryptography
I like explaining cryptography without the mystique. You can think about it like long division. A remainder is a one-way move. When the result of an operation is a remainder, you’ve thrown information away, you can't reconstruct the original.
That’s the heart of most modern cryptography. Functions that run easily forward, and not back.
Encryption? I give you the remainder (the encrypted text), but you can't work out the number I started with (the unencrypted text) unless you know the secret number I divided by (the key).
Hashes seem more complex. How do you get that random looking data from a line of text, in a predictable way? Instead of that tangle of logic gates, you can just think of it like a remainder (the hash) changing when the numerator (the input text) changes.
When you see a complex cryptographic system, you don’t need to internalize every algebraic detail. Swapping it out for remainders helps you understand what's going on.
Seeing what it can do
A hash gives you proof some data hasn't changed. A key pair lets you make something only accessible to one recipient, or prove it came from its source. HD key generation lets you predictably create unlimited keys from a single secret number. Commit-reveal lets you lock in a choice now, prove it later.
It takes a bit of time, but strip away the jargon and you’re left with properties: one-wayness, opacity, verifiability, predictability, timing.
Those are building materials.
Once you see them as material rather than prepackaged products, you start noticing all the uses that weren’t in the original manuals.
Sessions without tracking
Here's something I've been playing with.
User tracking exists because, in many cases, servers need to connect isolated page requests to specific users. So we got cookies, and with cookies we also got session IDs, user profiles, knowing what users have done. This let us make more useful websites for users. But decades after, we saw that servers don’t stop hoarding user data, and that turned septic. GDPR appeared to try and fix that. A legal fix.
HD (hierarchical deterministic) key generation gives us another way.
A browser generates its own random identifier. The server treats that identifier the same way an account number gets used with a seed phrase: a way to get a new set of encryption keys, just for that user, and just for that request.
On the server side, the only things you keep are the browser’s random ID and a counter for each request. No user data at all.
The server encrypts whatever state it needs. Authentication data, rate-limit counters, feature flags, and sends the encrypted blob back to the browser to store locally.
Each page request, the server uses its root key, the user's random ID, and the counter, to get the decryption key it needs to decrypt the data. Then it re-encrypts what it needs with the next key pair, and sends it back to the browser.
No cookies. No "we value your privacy" pop-ups tricking us into clicking the wrong thing.
Servers can still customize content, enforce access limits, respond to user context. But the users data stays safe and encrypted, in their own custody on their own device. They can delete it all themselves.
This privacy win isn't theoretical. It's structural.
HD key generation has existed since 2012. GDPR arrived in 2018. The tools to avoid surveillance-grade storage were sitting in plain sight; we just didn’t think to use them this way.
The real work is play
Mathematicians keep inventing new cryptography. Elliptic curves, homomorphic encryption, zero-knowledge proofs. We're getting breakthrough after breakthrough that genuinely expand what’s possible. But going from a modern ZKP course back to this old paper made something obvious: we're still just scratching at what the early primitives can do.
The limiting factor isn't the crytography itself. It's that we don't understand what we already have. Maybe we tell ourselves it's too hard, maybe marketing people and academic experts make it sound harder.
Joera—another friend—has been building a publishing system for journalists. Not just proof of authorship; actual author control. A writer can revoke access to their work after publication, or move it elsewhere, and the proof structure follows them. No platform lock-in. No hostage situations disguised as CMSs.
I’m working on a cryptographic ticketing system for conferences, trying to solve the RSVP problem. Everyone signs up for a bunch of events but attends one, which leaves organizers guessing and events half-empty. Cryptographic tickets can turn this fomo into a positive signal game, all without surveillance.
A bunch of us hang out weekly. We're in chat helping each other on our projects, showing each other cool stuff, thinking out loud. We play with the primitives we have.
Most people think of Mental Poker as a fun aside—the RSA trio goofing around. Nerd-sniping us with a niche puzzle about modems and poker.
But rereading it now, it feels like they were leaving a message in the margins: the space of possible applications is much wider than we think. We just need to ask, “What else can this do?”
RSA were trying to show us that we already have what we need. They weren't making in-jokes for cryptography nerds, they were inviting us to play too.