Finally! Johnny CAN Encrypt

The Unkept Promise of Strong Cryptography

Whenever I have to explain what cryptography is to someone, which I frequently do, the first thing I tell them is that:

Anything you do to secure information is cryptography, and, in that sense, cryptography is something that every human being naturally does.

Next, I tell them this:

That means computers give math physical predictable costs, in energy and time.

For instance, there are certain math problems that can be solved in one direction with a trivial number of operations, but are completely infeasible to do the other way, unless you already know a part of the answer. They would take astronomically more time and electricity than anyone has.

Because of this we can use them in clever arrangements to bind information in the physical world. Many of the ways we do this resemble physical signatures and keys. But, unlike physical signatures and keys, if used correctly, they cannot be forged or broken.

This is what we mean by "strong" and the implications are profound. Rules that cannot be broken, don't require any enforcement. A door that cannot be opened needs no guard.

The promise of strong cryptography is that we can truly secure the digital information that increasingly undergirds our real lives and our civilization: our identities, our relationships, our interactions. And that we don't have to give up our freedom to do it.

If this doesn't sound much like how the world currently works, you are not wrong. This is the promise of strong cryptography, but it is a promise that hasn't been kept. The question of why, and how we're going to fix it, is the subject of the rest of this essay.

The Crypto Wars

For thousands of years, in the absence of such tools, we have had to resort to systems that rely on force to secure the world. But then, as stronger cryptography emerged in the 1980s, there were some cryptographers who saw its promise to create order without coercion, and wanted to see that promise realized. They called themselves "cypherpunks" and they set out to build the tools that would keep this promise to the world. Unsurprisingly, the institutions responsible for maintaining order under the old paradigm were not very comfortable with this.

In 1991, Philip Zimmerman and his team released one of these tools: PGP, or Pretty Good Privacy, in hopes of giving everyone access to the power of strong cryptography. This kicked off a struggle between the systems in power on one side and cypherpunks and the people and companies who wanted to use cryptography for practical reasons on the other. This struggle is unofficially known as the Crypto Wars. While the struggle has never really ended, authorities have substantially relented in the face of inarguable security value, and restrictions were gradually loosened.

PGP and its descendants have become universally available and critically important to the integrity of our infrastructure. In a sense, the cypherpunks won the Crypto Wars: the genie is out of the bottle, but in another sense, the promise of strong cryptography is still not realized in the world.

We have the tools. We have the freedom to use them. But we have only scratched the surface of putting them into practice, and only a fraction of their true promise has been delivered. The applications remain narrow and specialized. They have not been truly woven into the fabric of society: leaving us woefully insecure and subject to messy, expensive and even oppressive ways of organizing ourselves under primitive systems of surveillance and enforcement.

The obvious question is "why" but it's a question that's withstood decades of study.

The Johnny Problem and The Crisis In Cybersecurity

In the late 90s, researchers did a study on the usability of PGP, trying to understand why it was not more broadly adopted. What they found was that even motivated, technically literate users could not successfully use PGP to send an encrypted email. People generated keys incorrectly, confused public and private keys, couldn't figure out how to find or verify someone else's key, and frequently couldn't tell whether a message had actually been encrypted. The researchers concluded the problem was usability and recommended better interface design.

Seven years later, a second team ran the same study with a newer version of PGP. Same result. Nine years after that, a third team ran it again with Mailvelope — a modern, well-regarded PGP client built to integrate cleanly with webmail. One pair out of ten succeeded within the hour allotted. Same result. Same recommendations.

These papers became known as the Johnny papers, named for their titles: "Why Johnny Can't Encrypt," "Why Johnny Still Can't Encrypt," and "Why Johnny Still, Still Can't Encrypt." 1999, 2006, 2015. Same answer. Thirty-five years on from the release of PGP and the received wisdom is that UI for cryptography is just too hard.

Meanwhile, while the adoption of strong cryptography has stalled, the consequences of extending the enforcement paradigm over the digital world have become more serious in important ways. The digital world itself has extended into the physical world. Whether you share the dream or the ideological perspective of the cypherpunks or not, the stakes have been raised. The global cost of cybersecurity incidents is estimated to have exceeded $10 trillion dollars in 2025, and to be rising more than 10% year-over-year. Critical infrastructure: energy, water, emergency services, supply chains, the defense industrial base, etc., is more sophisticated and more reliant on networks and control systems which are actively being targeted and penetrated by foreign adversaries at alarming rates. Johnny's problem has become an economic problem and a national security problem.

The prime example of how this plays out, concretely, is telling. In order to secure our systems under the old paradigm, permission is granted in the form of a credential: a password, a token or a certificate. The root of trust is the institution, and to enforce access control users are required to present a credential at the point of access. This requires knowledge of valid credentials to be stored in the network or system being accessed so that it can perform the check, creating a high value target. The result is that 85-90% of all breaches involve stolen credentials, using them to execute the attack and/or targeting the credential store itself. They are sold on dark markets and recyceled into the next attack, fueling the economics of cybercrime and enabling hostile foreign actors.

The response so far is a new generation of cybersecurity products that go by the name of "zero trust". But what they do in practice generally is repeat the mistake at scale, aggregating control into more centralized and increasingly invasive control planes, creating even higher-value targets. This also introduces friction and massive failure modes into systems, of which the CrowdStrike outage of July 2024 is a striking example. At a societal level we are following the same pattern of surveillance and enforcement escalation as well.

The crowning irony of all of this is that these enforcement regimes themselves, both technological and institutional, are being weaponized by our adversaries more and more directly. Take the the recent software supply chain worm, called CanisterWorm, targeting security tools. The digital world doesn't work the same way that the physical one does and these approaches are failing miserably. We continue to double down on trading freedom for safety and we're getting neither.

If I sound frustrated, I am. All of this has been on my mind for a long time.

The Real Problem

In 2002, as a young software engineer, I read the PGP manual, and as I was reading it I came to a particular section on something called the Web of Trust. The concept is this: everybody has a key, with a public part that serves as an identity which they share, and a private part that they can use to sign things. Anybody who knows your public key can verify any signature you have made using your private key, and that the data you signed has not been tampered with. Any two people who know each other's public key, can enrypt messages that only they can read. But how can we trust who a public key belongs to? PGP's answer is that we can sign the keys of people we know and tell PGP how much we trust them. We can share these signatures and when presented with a key, we can see if other keys we trust have signed it and decide if we trust it too.

This idea is a simple but powerful example of the kinds of things that we can do with cryptography and in that moment the potential of cryptography to change the way the world works in a profoundly good way struck me very deeply. It was such a strong moment that I remember how the room sounded, how the air felt. But at the same time, I was already well aware of both the apathy and the resistance of many people around me to using cryptography. "What have you got to hide?" "Why bother?" When I tried to talk to people about it, even other technical people, sometimes I would get eye rolls. One time I'll never forget, someone literally laughed in my face.

Mostly though, I heard people telling me exactly what the Johnny papers say: that it's too hard. It's not practical for broad use. As a software engineer, however, this never satisfied me. In software design we have a pair of opposing concepts we use to think about how simple things should be: "essential complexity" vs "accidental complexity". Accidental complexity is when you have made something more complicated than it really needs to be. Essential complexity is what's left when something is as simple as it can be without changing what it is.

What I came to believe is that the deeper reason Johnny can't encrypt is that the job of using cryptography just involves a lot of things that can't really be done for the user without breaking security. (And the papers do kind of hint at this, calling it "ceremony".) Simply put, taking responsibility for your own security by playing this game of keys and signatures with existing tools is hard and no amount of UI design can really fix it.

But still, the potential benefit is so great that the problem stayed stuck in my mind: an irritant that was always there. When we are not able to solve for essential complexity in the things we build and leave it to the user, that's not bad UI. It is not the case that somebody just needs to put the buttons in the right place. What it means when a problem like this persists is that the architecture is wrong. What it means is that we just don't fully understand the problem yet. So I kept returning to it in idle moments. It was like a puzzle that I couldn't walk by without stopping to frown at it for a moment or two. Anything that looked like progress or a clue, would always grab my attention.

Lessons From Bitcoin Users

Though the field of applied cryptography did continue to slowly mature, the most important lessons accrued to the people struggling with it in the wild, on their own, with real skin in the game. In 2009, an unknown person using the pseudonym Satoshi Nakamoto published a paper describing an electronic cash system called Bitcoin. His invention kicked off an experiment on a scale and under conditions that no researcher could ever produce.

The problem of money is arguably the greatest of all trust problems and, therefore, the most important domain of cryptography. Money is, if you think about it, always and everywhere a cryptography problem and all forms of money (aka monetary media) are cryptography implementations. Even a bead, a shell or a ledger marked on a cave wall are all ways of securely encoding information about the exchange of value. It's our attempt to create a fair scoreboard, so that people can claim just rewards for providing value to others. The moment something becomes money, it becomes cryptographic.

What is critically important about the example of Bitcoin is that it is such a deeply trustless system. It solves the greatest trust problem, the one at the heart of building civilizations: the problem of working together with people we don't know or even with enemies, without appealing to any enforcing authority. That is to say, as a cryptosystem, it is complete and uncompromising in an unprecedented way. Further, because it caught on and became valuable without any central authority, it created a unique incentive for innovation in practical applied cryptography solutions to develop in the wild. People holding Bitcoin keys had to own and operate their keys without institutional fallbacks and the consequences for losing them or allowing them to be stolen were permanent.

The tooling in that space is still maturing too, and though it has been narrowly focused on the specific use cases of Bitcoin, the body of experience and the work that has been done have moved applied cryptography as a practice beyond academic theory, organizational best practices and usability studies in a unique way. What I saw happening on the ground in Bitcoin started to give me a sense that many pieces of the puzzle of Johnny's problem were finally on the table. And even more importantly, it stands as a demonstration of a deeper point that tells us how to put them together.

How To Solve It

The core insight is this: trust and accountability are two sides of the same coin. The key to architecting a complete and functional general-purpose cryptosystem is that only the individual human actor can be the root trust. Identity, relationships, organizations, connectivity and action must be secured to the accountable party without any gap. This may sound philosophical, and perhaps even obvious when stated so, but the technical consequences of building software from the ground up according to this reality are both hermetic security and effortless usability. It solves both these problems, that have been perceived for so long to be at odds, in one move: by closing the space between authority and responsibility, because that is exactly where security was breaking down and complexity was leaking.

The first question this leads us to is self-custody, and the answer is known as a seed. It is one secret that each user keeps, from which all other keys are created and can be recovered. Keys, and even passwords for legacy systems, can be derived to generate a hierarchical deterministic (HD) set of secrets. Boiling a user's ownership of their identity down to a single secret is the smallest possible irreducible form of the identity problem.

Seed responsibility is the principal trade off we must make, but it is the correct one, and the only one that holds. Making it easy to keep that seed safe, so that it is never lost or stolen, is a responsibility of cryptography tooling and any attempt to avoid it creates systemic risk. But, thanks to hard-won lessons provided by Bitcoiners over the past 17 years, this is now a well understood and highly automatable process. Seeds can be handled offline, split into recovery shards and geographically or socially distributed. This is how the gap between authority and responsibility is closed.

Another critical point is that privacy is security. Bruce Schneier, arguably the world's most well known and respected cryptographer, has been trying to shift our perspective on privacy with this understanding for a very long time. We know this viscerally, and that is probably why we have a natural psychological need for privacy and it seems fundamental to our dignity. The mistake we have made, under a paradigm relying on enforcement instead of math and physics for security, is to see privacy and security as a trade off, leaving us unable to achieve either. Strong cryptography removes this contradiction. What cannot be targeted, cannot be attacked.

Following from this comes another point: that identity is relational. The mistake we have been making here, and even PGP made this mistake, is relying on publicity as the basis of identity. That is not how real life works. You may have different identities in different contexts, but you don't want to reveal your entire life every time you interact. With hierarchical deterministic keys derived from a seed, the proliferation of keys becomes invisible and essentially free. Software should generate dedicated keys for every relationship, connection or context.

Another piece of the puzzle is liveness. There is a phenomenon known as trust rot or key rot. In the real world, trust between parties has to be maintained with ongoing interaction. The traditional solution to this in cryptography has been key expirations, but this is backwards. My trust for another party does not decay on their schedule. It belongs on the side of the one extending the trust. Fresh keys should be exchanged over existing cryptographic relationships periodically and with a frequency that satisfies both parties.

What this points to is the need for connectivity as a primitive of a functioning cryptosystem. We have built key management systems without connectivity and networks with cryptography bolted on for security. To create a fully functioning cryptosystem or truly secure networks, connectivity must emerge naturally from the cryptographic relationships and those relationships must use that connectivity to maintain liveness.

All of this works together to align the architecture of cryptography software with the structure of real life, and leads to the final and most important consequence: the user shouldn't, and doesn't have to, do anything special to use strong cryptography. Cryptography, like most technologies when they are done right, becomes invisible. Managing our relationships is something we already do. Without even thinking about it, we interact with our contact managers every time we meet someone, make a phone call or send a message. Modeling our organizations, granting and revoking roles which we govern, is something that everyone involved in running one does. Network administrators are specifying the rules of access to their resources in the regular course of their work. The user is already giving us all the information we need to implement strong cryptography for him.

With the right architecture, strong cryptography can just work.

The Solution

Finally, about two years ago, I was overcome with the sense that I was ready, so I sat down to solve the puzzle. After a lot of designing, research and experiments everything began to fall into place. The result is what we're building. We call it Zsub and its protocol is Self-Sovereign Cryptographic Mesh or SSCM. We're writing it from scratch in Zig. It's cross-platform, fast, has a build size we believe we can keep under 10MB, is not much bigger in memory and our only dependencies are Zig and libusb on Mac.

Zsub is still in development, but the hard part is done. We are releasing major components as they are completed so that public feedback and hardening can begin. The three main components are a secure runtime, a key database with high-level cryptographic protocols and a network layer with link security, transport, overlays and services. The key database and its protocols are the core. In this section I will describe Zsub as a complete system and in the next I will describe the recent release, the release of that core.

Here are the major features of Zsub:

Secure Self-Custody and Operational Security

Zsub has a secure runtime which isolates keys and cryptographic operations in a dedicated agent process, similar to ssh-agent or gpg-agent. All operations are offline-first. Keys are kept in mlocked secure memory (on systems that support it), encrypted at rest and decrypted in-place on-the-fly.

Secure buffers are provided where needed for sensitive operation and immediately zeroed. The seed can (and should) be removed offline and moved off-site, ideally geographically distributed as k-of-n recovery shards on steel plates. A dedicated device (SeedSigner supported) can be used to generate the database in a high-security configuration and set up a security card for gating certain operations.

Key access control is tiered: cold, cool, warm and hot.

• Cold can be retained public-key-only, so that information can be encrypted such that it can only be accessed again by retrieving the seed.
• Cool secret key should be kept offline but accessible for air-gapped operations, like audit logs that can only be opened offline.
• Warm can be protected with a security card (YubiKey supported) so that access to it requires device presence and a tap.
• Hot can be unlocked automatically when the database is open, supporting automation.

The database itself is also encrypted at rest, with a "shield key" stored in encrypted slots in a LUKS-like header. These are encrypted to a passphrase via Argon2 or ECDH to the Yubikey.

Key Database and Cryptographic Protocols

The user can organize keys in a free-form hierarchy. Every key lives in the hierarchy in a rich data structure called a Starfort. This is critically important because lineage, names, metadata and peering relationships place keys in a meaningful context that is comprehensible to the user and the protocols, something that's been largely missing in other tools.

Each Starfort includes essential metadata, like context string, timestamp, epoch, some flags, and a peer public key for key exchange. Keys can have additional external metadata stored encrypted to the key. Each key is derived from its parent, unless it is grafted into place. Multiple curves (types of keys) are supported for interoperability.

Freshness is preserved by ongoing key rotations, which cascade down the hierarchy. Rotation pauses on keys that need to complete a key exchange to rotate in tandem with a peer, and then continues down the tree when it can. Subtrees can be synchronized with other peers. The entire database can also be cloned to multiple devices and clones stay in sync.

Keys can be peered by an out-of-band key exchange by QR code, NFC tap or over pre-existing secure channels. Mutual password authentication can be used to secure the key exchange. Once peered, the key becomes a communications channel. A group of keys under a common parent can also serve as an n-way channel between a group of peers.

A collection of cryptographic protocols for things like multisigs and sync operations runs over these channels. Any protocol message that establishes or elevates trust is not immediately processed, but deferred to a queue for the user to decide, e.g., signature requests or peering invitations.

Of particular note is a protocol which allows users to define an organizational structure: a set of roles, relationships and access requirements based on them. Other peers can be invited to join and attest to their relationships, tracing out an organization along its natural structure in a hidden web of trust according to a given set of rules. This is particularly interesting because it is where we address the cybersecurity crisis directly. Authorization proofs based on these trust networks allow us to secure network and service access without resorting to credential store or creating a target.

Self-Organizing Mesh and Services

We call our networks "self-organizing mesh" because the connectivity emerges from the cryptography. Every relationship you have to another person, between your devices, to networks or services that you access is secured by an exchange of dedicated keys. Peers can share network information with each other during key exchange and the network layer connection manager facilitates ongoing direct connectivity.

Peers can also expose services to each other. The simplest of these is a blind relay which also supports store-and-forward encrypted messages. This enables NAT traversal so that peers can find and reach each other without exposure.

Another built-in service is onion routing, to anonymize traffic so that users and systems become much harder to target.

Peers can also expose overlay network endpoints. Zsub creates a virtual interface for point-to-point virtual networking which may also be gated with the aforementioned authorization protocol. These endpoints even include a local OAuth2 IdP service to translate authorizations to JWT and make integrating many legacy applications easy.

Additionally, a Lightning-powered mint for Chaumian credits supports the formation of Bitcoin-based DePIN networks, which provide shared blind infrastructure to support Zsub networks.

Applications and Interoperability

Zsub includes native applications for Linux, macOS, Windows, Android and iOS. The applications look a lot like a contact manager. Password management, Bitcoin wallet, secure messaging, file transfer and backups are supported. Since Zsub is a general purpose and person-centered cryptosystem, rich interoperability is a key area of ongoing growth as the software matures.

On the top level, the user enjoys the simplicity of organized contacts and a queue of alerts, while advanced functions (e.g., creating an organization or adding a multi-sig) expand naturally as you drill down. Johnny shouldn't have to do anything much different from what he already does, or learn a whole new mental model for relationships and trust, but the option to go deeper is there if he needs it.

Our concern for the ease of the UI has been something that we've thought about from the very beginning. We can't deliver on the promise of strong cryptography or solve the crisis in cybersecurity unless we solve Johnny's problem too.

Our Latest Release: StarfortDB

With that, I'm happy to announce the first release of Zsub's second major component, and really its heart: StarfortDB. On Christmas Eve we shipped our first major component, the secure runtime. That release stood up the agent IPC protocol, secure user input, a command line interface, housekeeping like logging and process management, and some developer-facing interop for things like source control signing with Git, Minisign-compatible build signing, SSH and Nostr integration. It was a good place to start: a container and tools we ourselves could use every day while we worked. But the key database was just a placeholder: a simple pin-protected encrypted key.

StarfortDB is where the philosophy described above becomes working code. Every idea in this essay — the seed, the key hierarchy, relational identity, liveness, cascading rotation, peering as a communications channel, hidden webs of trust with selective disclosure auth — lives here. This is the piece that makes Johnny's problem solvable.

What's in this release:

• ▸A single seed. Every key in the database is derived from one secret you own and control. Lose a device, recover everything. No server, no account recovery email, no trusted third party. Just the seed.
• ▸Offline-first. All database operations and protocols work without network access, which is both security posture and resiliency discipline. It supports air-gapping and dedicated hardware, as well as store-and-forward fallback for intermittent connectivity.
• ▸The key tree. A hierarchical, hardened database of keys derived from that seed, supporting the multiple curve types needed for interoperability with Bitcoin, Nostr, SSH and other systems. Every key lives in a rich structure (name, context, metadata, peer relationships) that makes it meaningful rather than just a number.
• ▸Layered access control. Cold, cool, warm and hot tiers, so each key's exposure matches its actual threat model.
• ▸YubiKey support. Warm-tier operations can be gated behind hardware presence, a tap required. For higher-security configurations, the database itself can be bound to the device.
• ▸Peering and channels. Key exchange establishes a dedicated encrypted channel between two parties. Groups of keys under a common parent become n-way channels. This is the foundation of the self-organizing mesh.
• ▸Consentful trust. All inbound messages that establish or elevate trust are presented to the user for approval before processing.
• ▸Multi-device continuity. Full database cloning and graft-sync for sharing subtrees with selected peers, so your keys stay consistent across devices without any central server in the path.
• ▸Heavy. Privacy-preserving authorization: peers can prove they satisfy a trust requirement without presenting credentials or revealing more than the proof requires. This is how we address the credential-store problem directly.
• ▸Secrets. Passwords, notes, and TOTP tokens stored in the database. Passwords can also be generated deterministically from the seed. If lose a device, recover them without ever having stored them. No separate password manager, no cloud sync, no breach surface.
• ▸Ratchets, long-term encryption, MuSig2 and VRF support. The cryptographic substrate for the protocols the rest of Zsub will build on.

The full documentation, covering the architecture, core concepts, API reference, and the protocol specification is at the repository. The README is a good starting point, and there is a quickstart guide and a demo-grade CLI if you want to get your hands on it.

From here we will complete the network layer, which is well underway, before the first release we'll call Zsub proper. That will be followed by hardening, third-party audits, and native applications. We'll be releasing as components are ready, as we have done here, so that review and hardening can begin in public. If you're a developer, a security researcher, or someone who has been waiting a long time for strong cryptography to actually work, we'd love your eyes on it.

The cypherpunks were right about what was possible. Given the state of cybersecurity, they may have even underestimated how badly we needed it. They were just a few hard problems short of being able to deliver it. We think those problems are solved now. Time to find out.