Why You Should Never Let a Provider Generate or Store Your Private Key

Modern encrypted communication platforms often advertise end-to-end encryption and zero-access security. But beneath the marketing language lies a critical technical reality:

If a provider generates or stores your private key, even in encrypted form, the system is not zero-access.

This article breaks down why true zero-access cryptography requires that users generate, protect, and retain sole custody of their private keys. The provider should only have access to the public key and never even touch the private key, not even once. Anything less introduces hidden trust assumptions that undermine the entire security model.

Zero-Access Begins With Key Ownership

In any asymmetric encryption system, the foundation is simple. Your public key is meant to be shared freely, and your private key must never leave your possession. The public key lets others encrypt messages to you; the private key lets only you decrypt them.

A zero-access system rests on three conditions. You create your private key on hardware you control, using software you choose. You never upload that private key to any third-party service, ever. And you never depend on the service doing the encrypting to generate, manage, or store it.

If a provider ever touches your private key, even once, the system transitions from zero-access to trust-required.

Client-Side Key Generation Delivered by the Provider Isn't Trustless

Some services attempt to bridge convenience and security by generating your key pair "locally in the browser." It sounds reassuring, but the model has a fundamental flaw: the provider supplies the JavaScript that generates your private key.

Because the service controls the code delivery path, that same code can generate weaker keys, leak the private key before it is ever encrypted, record your password, draw on predictable or compromised randomness, or be delivered in a malicious form to specific targeted users while everyone else receives the clean version.

To believe none of that is happening, you have to trust that the code was not tampered with, that it was not selectively modified under legal compulsion, that it was not served differently to your device than to anyone else's, and that the build pipeline behind it was never compromised.

That is not a trustless environment. It is trust disguised as convenience. In cryptographic terms, code delivered by the adversary cannot be part of the trusted computing base.

Randomness Matters, and Providers Control It During Keygen

Strong keys require high-quality entropy. When a provider's code generates your keys, you inherit whatever that code brings with it: its choice of random number generator, the quality of its entropy, any implementation bugs or latent weaknesses, and even deliberate reductions in key strength.

Weak randomness equals weak keys, and weak keys equal broken encryption. Zero-access demands that the user, not the provider, controls the entropy source and the key generation itself.

Private Keys Should Never Be Uploaded, Even Encrypted

Some systems require the user to upload a private key so the platform can decrypt content in its own environment. This violates the core principle of asymmetric cryptography. It does not matter whether that private key is encrypted, password-protected, hardware-derived, or obfuscated; once uploaded, it still resides with the provider.

And any time decryption happens in a provider-controlled environment, the provider can in theory capture the plaintext, capture the password, log the decrypted private key, or intercept the decrypted data stream. A zero-access system does not permit the provider to be part of the decryption path in any fashion.

Real Zero-Access Means Local-Only Decryption

A genuine zero-access encryption architecture has four defining properties.

First, the service may store or distribute your public keys, which is harmless, because public keys are designed to be public.

Second, your private keys never leave your devices. They are not generated by the provider, not imported into the provider's environment, and not accessible to any code the provider delivers.

Third, decryption happens exclusively in software you selected. Not inside a browser environment controlled by the service, not in JavaScript downloaded dynamically, and not inside provider mobile apps, especially PWAs (Progressive Web Apps), which are basically just a browser tab dressed in app clothing.

Fourth, key management and password handling remain entirely client-side. Your keys are stored securely, used exclusively by trusted local tools, and never shared upward into the provider's infrastructure.

Together these preserve the fundamental asymmetry of the cryptosystem: the service encrypts for you, but cannot decrypt on your behalf.

The User Should Upload Only Public Keys, Nothing More

In a properly designed system, the flow is straightforward. The user uploads only a public key. The provider uses that public key to encrypt messages. The user decrypts privately, using a local-only private key the provider never sees. As a result, the provider never has the capability, technical or legal, to access the content.

This model, though more demanding to implement cleanly, is the only cryptographically sound way to achieve zero-access communication.

Control the Key, Control the Security

If a service generates your private key, it can replace it, copy it, weaken it, or add a back door. If it stores your private key, it can access it, even if it needs a "passphrase". If it delivers the decrypted content, it can copy it.

The integrity of an encrypted system depends entirely on who controls the private key and how.

Zero access means the provider never touches, hosts, generates, or decrypts with your private key. Not even once. Not even "encrypted." Not even "client-side."

Anything else is trust by design, not trustless by architecture.

Edited to reflect zero-access and not zero-trust.