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:

• Public key - shared freely
• Private key - never leaves your possession

The public key enables others to encrypt messages to you. The private key enables only you to decrypt them.

A zero-access system requires that:

• You create your private key on hardware you control with software you choose.
• You never upload the private key to any third-party service, ever.
• 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."

But this model has a fundamental flaw:

The provider supplies the JavaScript that generates your private key.

Because the service controls the code delivery path, it can:

• Generate weaker keys
• Leak the private key before encryption
• Record your password
• Use predictable or compromised randomness
• Deliver malicious code to targeted users only

You must trust that:

• the code wasn't tampered with
• it wasn't selectively modified under legal compulsion
• it wasn't served differently to your device
• the build pipeline wasn't compromised

This 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 their:

• random number generator choice
• entropy quality
• implementation bugs
• potential weaknesses
• or 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 entropy sources and key generation.

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 their environment.

This violates the core principle of asymmetric cryptography.

Even if the private key is:

• encrypted
• password-protected
• hardware-derived
• obfuscated

…it still resides with the provider.

And any time decryption happens in a provider-controlled environment, the provider can theoretically:

• capture the plaintext
• capture the password
• log the decrypted private key
• 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 these properties:

1. Public keys are stored or distributed by the service

• This is harmless.
• Public keys are designed to be public.

2. Private keys never leave the user's devices

• Not generated by the provider
• Not imported into the provider's environment
• Not accessible by provider-delivered code

3. Decryption happens exclusively in user-selected software

• Not inside a browser environment controlled by the service
• Not in JavaScript downloaded dynamically
• Not inside provider mobile apps, especially PWAs (Progressive Web Apps), these are basically just a browser tab dressed in app clothing

4. Key management and password handling remain entirely client-side

• Stored securely
• Used exclusively by trusted local tools
• Never shared upward into the provider's infrastructure

This preserves 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 user uploads a public key.
• The provider uses that public key to encrypt messages.
• The user decrypts privately using their local-only private key.
• The provider never has the capability - technical or legal - to access content.

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

TL;DR: 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