TempSafe v2: A Minimal Zero-Knowledge Design for Sharing Secrets

A practical design for temporary secret sharing: encrypt in the browser, keep the server blind, expire by default, and avoid turning small-team security into enterprise theater.

Secrets should not live forever just because someone pasted them into chat

Small teams leak secrets in boring ways.

Not through elite attackers. Not through cinematic breaches. Through Slack messages, email threads, screenshots, copied API keys, shared passwords, client documents, PDF attachments, and "I'll delete this later" promises that quietly become fossil records.

For startups, freelancers, clinics, agencies, law firms, consultants, and small IT teams, the security problem is rarely that they reject good practices. It is that secure tools often feel too heavy for the moment. Enterprise secret managers are powerful, but they assume process maturity. Consumer password tools help individuals, but they do not always fit short-lived, one-time sharing. So teams fall back to the nearest channel: email, chat, or a shared note.

TempSafe is a design thought experiment for that gap.

The idea is simple:

A secret should be encrypted before it leaves the sender, readable only by the intended recipient, and designed to expire by default.

Not stored forever. Not visible to the server. Not dependent on everyone creating accounts before the work can continue.

TempSafe is not meant to replace full enterprise secret management. It is a smaller pattern: temporary, zero-knowledge secret sharing for teams that need something safer than chat but lighter than a full platform migration.

The problem: insecure sharing is usually convenient sharing

Most accidental secret exposure happens because the unsafe path is faster than the safe one.

A developer needs to send an API key. A client needs to send a document. An agency needs temporary credentials. An admin needs to share a recovery code. Someone says, "Just WhatsApp it," or "Send it on email," and the secret begins its new life as a permanent searchable artifact.

That creates several problems:

1. The sender cannot reliably revoke access.
2. The recipient may forward or store the secret accidentally.
3. The platform carrying the message may retain it indefinitely.
4. Plaintext copies may exist across notifications, backups, search indexes, and logs.
5. There is often no clean audit trail, expiry model, or access boundary.

The uncomfortable truth is that many teams do not need a more complex secret-sharing process. They need a safer default that feels almost as easy as pasting into chat.

The TempSafe model

TempSafe is based on five design principles.

1. Encrypt on the client

The secret is encrypted in the browser before it is sent to the server.

The server stores only ciphertext and minimal metadata. It should not be able to read the secret, reconstruct the key, or recover the plaintext. This keeps the trust boundary small: the server can deliver encrypted data, but it cannot understand it.

A typical flow would look like this:

1. The sender enters a secret in the browser.
2. The browser generates a random encryption key.
3. The secret is encrypted locally using authenticated encryption.
4. The encrypted payload is uploaded to the server.
5. The decryption key is kept in the URL fragment or derived from a passphrase.
6. The server never receives the plaintext or usable key.

The important detail is the URL fragment. In a URL such as:

https://example.com/s/abc123#client-key

https://example.com/s/abc123#client-key

the part after # is normally not sent to the server. That makes it useful for carrying a client-side decryption key, provided the implementation is careful.

This is not magic. It still depends on secure frontend delivery, careful browser code, and protection against phishing or malicious script injection. But it changes the server from "keeper of secrets" to "carrier of encrypted envelopes."

2. Expire by default

A temporary secret should behave like a temporary secret.

TempSafe would make expiry part of the core model, not an optional afterthought. A sender could choose:

• one-time view,
• expire after 10 minutes,
• expire after one hour,
• expire after one day,
• expire after a custom time window.

After expiry, the encrypted payload is deleted or made inaccessible. The system should also make the expiry visible to both sender and recipient. Security should not depend on hidden timers and wishful thinking.

The goal is not to make copying impossible. Any recipient who can read a secret can copy it. The goal is to reduce unintended persistence: fewer forgotten messages, fewer searchable keys, fewer long-lived links, fewer secrets buried in communication history.

3. Add a second lock when needed

A link alone is not enough for sensitive secrets.

TempSafe should support an optional passphrase. In that mode, the browser derives the decryption key from the passphrase using a memory-hard key derivation function, then decrypts the payload locally.

This creates a useful split:

• the link carries the location,
• the passphrase carries the authority.

The passphrase should be shared through a different channel. For example, the link may go over email and the passphrase over a phone call or secure chat. This is not perfect security, but it is dramatically better than sending the whole secret in one place.

The system should also avoid pretending passphrases solve everything. Weak passphrases remain weak. A safe design should include minimum strength guidance, rate limits, and clear warnings without turning the interface into a compliance punishment device.

4. Keep the server boring

Security systems often become dangerous because they are overbuilt.

A minimal TempSafe server might need only a few core operations:

• create encrypted secret,
• retrieve encrypted secret,
• delete or expire secret,
• optionally record encrypted audit metadata.

The server does not need to know the secret. It does not need a rich user profile. It does not need searchable message bodies. It does not need to become a collaboration suite, document manager, chat app, and dashboard beast, though product teams everywhere will immediately try.

The more the server knows, the more it can leak.

A boring server is a defensive feature.

A practical reference implementation could use:

• static browser frontend,
• WebCrypto for encryption,
• strict content security policy,
• signed frontend assets,
• small .NET Minimal API or equivalent backend,
• ciphertext-only storage,
• scheduled cleanup,
• rate limiting,
• basic abuse detection,
• no plaintext logging.

The strongest version of TempSafe is not the version with the most features. It is the version whose failure modes are easiest to understand.

5. Adapt only where adaptation helps

The original TempSafe idea included adaptive defenses: rate limiting, honeypots, decoy links, geo-fencing, self-pausing secrets, and suspicious access detection.

Those ideas are useful, but they should be handled carefully.

Adaptive security can become theater if it is not tied to a clear threat model. A good minimal version might start with:

• throttle repeated access attempts,
• lock retrieval after too many failures,
• alert the sender on suspicious access,
• expire secrets early after abnormal activity,
• use decoy routes to identify automated scanning,
• avoid revealing whether a secret ID exists.

That is enough for a first version.

More advanced features such as device attestation, threshold cryptography, offline unlock, or dynamic key rewrapping can come later. They belong in a roadmap, not in the minimum design. Security products often fail because they try to be military-grade before they become usable.

What TempSafe should not claim

A design like this should be honest about its limits.

TempSafe would not stop a recipient from copying the secret. It would not protect against a compromised browser. It would not save a user from entering the secret into a phishing page. It would not make weak passphrases strong. It would not remove the need for proper credential rotation, least privilege, or audit controls.

It also should not claim to be "unhackable." That word belongs in marketing decks and other hazardous waste.

The correct claim is narrower:

TempSafe reduces the amount of plaintext secret material that travels through ordinary communication channels.

That is already valuable.

Where it fits

TempSafe would be useful for:

• sharing temporary credentials with a contractor,
• sending a recovery code to a client,
• passing an API key during onboarding,
• sharing a short-lived document with a legal or finance contact,
• giving an MSP temporary access information,
• sending secrets where full account setup would create friction.

It is not a replacement for a mature secrets manager. It is a bridge between unsafe ad hoc sharing and heavyweight enterprise tooling.

That bridge matters, because many small teams live in the gap.

The design test

A useful TempSafe implementation should pass five tests:

1. Can a non-expert use it without training?
2. Can the server read the secret?
3. Does the secret expire by default?
4. Is the failure mode clear?
5. Does it reduce unsafe sharing in real workflows?

If the answer is yes, the design is worth building.

Closing thought

Security should not require every small team to behave like a Fortune 500 company.

Some teams just need a safer way to send one secret once.

TempSafe is a proposal for that narrower, humbler problem: encrypted before upload, temporary by default, boring on the server, and honest about what it can and cannot protect.

The best secret-sharing tool is not the one with the most impressive dashboard.

It is the one that prevents the secret from becoming another permanent message in a chat history nobody meant to preserve.