Product comparison
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. The sender needs a Secretus account and trial or paid plan; the recipient does not need an account. One-time access is the Standard-mode default, and live P2P carries the payload without writing it to server storage. Hybrid post-quantum key agreement, Shamir k-of-n team splitting and secret requests extend that workflow.
Side by side
| Feature | Secretus | Bitwarden Send |
|---|---|---|
| Client-side encryption (browser) | ||
| Server stores only ciphertext | ||
| One-time by default | Yes — link invalidated before payload response | Optional maximum access count |
| Account requirement | Sender account; recipient needs none | Sender account; recipient needs none |
| 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 a one-time default with link invalidation before the payload response, rather than configuring an access count.
- • 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?
Yes, for the sender. Secretus requires an account and a 14-day trial or paid plan to create a share; the recipient can open the link without an account. Bitwarden likewise requires a sender account, and its file Sends require Premium access.
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 that reduces harvest-now-decrypt-later exposure — a future quantum attacker would have to break both the classical and the post-quantum layer; and Shamir k-of-n splitting so no single person or channel holds the whole secret.
Start a 14-day trial to send; recipients can open one-time links without an account.
Share a secret nowComparison reflects publicly documented behaviour checked on 3 August 2026. Spotted an inaccuracy? Tell us and we'll fix it.