Secretus vs Bitwarden Send
Credit where it's due: Bitwarden Send is a solid feature from a trusted password manager. It encrypts your text or file in the client before upload, the decryption key rides in the link, an optional password adds a second factor, and the server stores only ciphertext. If you already live in Bitwarden, it's a reasonable way to hand someone a secret.
Secretus is purpose-built for the transfer itself. Basic sharing needs no account on either side, one-time destruction is the default rather than an access count you configure, and there's a live peer-to-peer mode where the secret is never written to any server. Add hybrid post-quantum key agreement, Shamir k-of-n team splitting and secret requests, and the scope goes well beyond a send feature attached to a vault.
Side by side
| Feature | Secretus | Bitwarden Send |
|---|---|---|
| Client-side encryption (browser) | ||
| Server stores only ciphertext | ||
| One-time by default | Yes — atomic delete on first read | No — optional max access count |
| Share without any account | No account to send or receive | Sender needs a Bitwarden account |
| Send files | Yes (Business tier) | Premium only |
| Live P2P mode — secret not stored server-side | Authenticated X3DH-style + WebRTC | |
| Per-message key rotation in live mode | ||
| Post-quantum key agreement | Hybrid ML-KEM-768 (FIPS 203) | |
| Team k-of-n splitting (Shamir) | ||
| Request a secret from someone | ||
| Maximum link lifetime | You choose (short expiries) | Up to 31 days |
| Open source / self-hostable | Client code runs unobfuscated; hosted EU | Yes — fully open source |
When Bitwarden Send is the better fit
- • You and your team already use Bitwarden and want to send a secret without leaving the app you trust.
- • You want a fully open-source, self-hostable stack and are comfortable with senders having accounts.
When Secretus is the better fit
- • You send to people with no account — contractors, clients, auditors — with nothing to install or sign up for.
- • You want one-time destruction as the default, enforced atomically, not an access count you remember to set.
- • You sometimes need the secret to never touch a server at all — live P2P with per-message key rotation.
- • You want Shamir k-of-n team splitting and hybrid post-quantum protection against harvest-now-decrypt-later.
Frequently asked questions
Is Bitwarden Send end-to-end encrypted?
Yes — Bitwarden encrypts a Send in the client before it reaches their servers, and the decryption key travels in the link, so the server holds only ciphertext. That core is sound. The differences are scope and defaults: sending requires a Bitwarden account, one-time access is a limit you configure rather than the default, and there is no peer-to-peer, post-quantum, or Shamir-splitting mode.
Does Secretus need an account like Bitwarden does?
No. Basic one-time sharing on Secretus needs no account from the sender or the recipient. Bitwarden Send requires the sender to have a Bitwarden account, and file Sends require a paid Premium plan. Secretus reserves accounts for the paid team and workflow features, not for the act of sending itself.
What does Secretus add over an encrypted send link?
A live peer-to-peer mode where the encrypted secret goes browser-to-browser over WebRTC and is never written to a server; per-message key rotation inside that session; hybrid ML-KEM-768 (NIST FIPS 203) post-quantum key agreement so recorded traffic stays safe against future quantum attacks; and Shamir k-of-n splitting so no single person or channel holds the whole secret.
Try it yourself — share a secret end-to-end encrypted, no account required.
Share a secret nowComparison reflects publicly documented behaviour as of July 2026. Spotted an inaccuracy? Tell us and we'll fix it.
