Confidex
Your passwords are only yours.
Confidex keeps your passwords, codes, notes and files in a vault only you can open. The service that syncs it never learns your name, your email or your password, and it cannot read a single entry.
- No sign-up
There is no account on our side to steal, phish or reset.
- Sealed on your device
Encrypted and signed before anything leaves, if it leaves at all. Sync is optional.
- Free and open source
GPL-3.0 apps and an AGPL-3.0 sync server you can run yourself.
Everything a login really needs, in one place.
A record is not a fixed form. Put a password next to its one-time code, the recovery note, the card you pay with and the file you were emailed. It all stays together, and it is all encrypted together.
- Logins and passwordsWith a generator that keeps its settings on your device.
- One-time codesCodes for two-step sign-in, generated on your device.
- Bank cardsNumber, expiry and code as ordinary encrypted fields.
- Notes and documentsPlain, or protected so they stay hidden until you ask.
- Photos and filesScans, PDFs and pictures, resized on your device before they are sealed.
- Wi-Fi networksA QR code your guests can scan, built from the saved password.
- API keys and tokensHidden until you reveal them, copied in one action.
- SSH keysWith a native agent that asks you before every use.
- Your own fieldsAnything else you need. Nothing is dropped when you edit.
- Full historyEvery change is kept. Open any earlier version of a record.
Moving in is one import away.
Confidex imports from 1Password, Bitwarden, KeePass and CSV, and exports back to them. Try it with your real data, and leave with everything if you change your mind.
- 1Password
- Bitwarden
- KeePass
- CSV
Desktop
Real native applications for Mac, Linux and Windows, written in Rust with a GPU-accelerated interface. No Electron, no Flutter, no web view.
- macOS
- Linux
- Windows
Browser
Open app.confidex.me and start right away. After the first visit it works offline too, and it installs to a phone home screen.
Open app.confidex.meOffline first
Every device keeps the whole vault. Sync when you want, through our server or your own, or never: keep the vault on one device and back it up to a file. If two devices disagree, you see both versions and choose.
Two keys open your vault. Nobody holds both but you.
Your password and secret key open a small lock that holds the vault's private keys. Records are encrypted separately, and every revision is signed. The sync server checks signatures without receiving either unlock secret or requiring an account.
-
Your password
You remember it. It is never stored anywhere and never sent.
-
Your secret key
Your device keeps it. On a new device you type it once as a transfer code: 77 letters and digits in groups of seven.
-
The lock
Holds the vault keys and opens only with both. Argon2id makes every password guess slow on purpose: 64 MiB of memory and three passes per try.
One key alone changes nothing. A copy of everything on the server cannot even be used to guess your password, because the server never holds the secret key.
Your devices stay in step through a server that cannot look inside.
Every change leaves your device sealed and signed. The server passes sealed boxes between your devices and checks the signature so nobody else can change your vault. It cannot open a single box, and it works over plain HTTP just as safely as over HTTPS.
The server stores and forwards. Only a signature from your own key lets a change in.
Lock it, and it is gone from memory.
While the vault is open, the keys and the records you look at live in memory. When you lock it, Confidex drops them at that moment. Rust frees memory deterministically, without a garbage collector that might keep secrets around a while longer. Copies made by the clipboard or the operating system are outside this guarantee.
No garbage collector decides when your secrets leave memory. Locking does.
What happens if our server is hacked?
Switch on what the attacker managed to get hold of.
Switch on what the attacker has. The answer follows the threat model in the project documentation.
- Yes. Both keys together open the vault.This is the one real way in. It is also how you open your own vault on a new device, which is why the password and the transfer code must never be kept together.
- Yes. Both keys together open the vault.They can fetch the sealed data with the public address and open it. Keep the password and the transfer code apart.
- No, as long as your password is strong.The secret key lets them fetch the lock and try passwords offline. Every guess costs 64 MiB of memory and three passes of Argon2id. A long passphrase stays out of reach; a short one does not.
- No. The secret key never reached the server.A known password cannot even be tested against the dump. Deriving the lock key needs the secret key that stays on your devices.
- No. They have nothing to use it on.Without the secret key they cannot derive the lock key, and without the vault address they cannot even fetch the sealed data.
- No. There is nothing to guess against.The server holds no passwords, no password hashes and no secret keys. Without the secret key not a single password guess can be tested against the dump.
Use our sync server, or run the same one yourself.
The server is small because it has nothing to protect. It stores sealed boxes, keeps a counter per vault and checks a signature before accepting a change. Run it as a Docker image on any machine, or as a Cloudflare Worker on the free plan with no server of your own and nothing to pay. New vaults use sync.confidex.me; point them at your copy with one setting.
- Runs as
- A Docker image, a native binary, or a Cloudflare Worker on the free plan.
- Index
- SQLite or PostgreSQL natively, D1 in the Worker.
- Objects
- Any mix of S3-compatible buckets, plain directories and Git repositories. Writes go to all of them; reads fall back and verify digests.
- Transport
- HTTP or HTTPS, your choice. Boxes are sealed and signed either way.
- Accounts
- None. A vault registers by uploading its signed lock. Only the holder of the signing key can change it afterwards.
- Not at all
- Sync is optional. A vault can stay on one device, backed up to a local ZIP file, and never touch a network.
- License
- AGPL-3.0. Changes you run for others stay open.
What Confidex does not protect.
Cryptography defends data at rest and in transit. It cannot defend an unlocked device, and it cannot hide everything. These are the boundaries we know about, stated plainly.
An unlocked, infected device
While the vault is open, the keys and the records you look at are in memory. Malware running on that device can read them. Lock when you step away.
Shapes, not contents
The server sees vault and record identifiers, which revision follows which, timestamps and the sizes of sealed values. Contents, names, types and tags stay hidden; shapes do not.
A weak password with a leaked secret key
Someone holding your transfer code can try passwords offline. Argon2id makes every guess cost 64 MiB and three passes, so a long passphrase holds. A short one does not.
The local search index
Titles, web addresses, tags and unprotected notes are indexed in plain text on your device for search. The index never leaves the device, but anyone reading your disk learns those labels.
No forward secrecy
If the private vault material is ever exposed, records sealed under it can be read. Changing the password re-wraps the lock; it does not re-seal old revisions.
Copies outside the app
Clearing memory at lock covers what Confidex owns. The clipboard, the browser and the operating system can keep their own copies.
The construction, for people who check.
Pure Rust implementations with no C bindings. Every construction has fixed test vectors, and the storage format, the lock, the record encryption, the signatures and the sync protocol are each specified down to the byte.
The cryptography page follows one vault from its first random byte to a synced revision, step by step: how the material becomes two key pairs, how the lock is sealed and opened, how a revision is encrypted, signed and named, and what the server verifies.
- Creating a vault32 random bytes, X25519 secret key, Ed25519 signing pair, UUIDv5 address, 77-symbol transfer code.
- The lockArgon2id 64 MiB, HKDF-SHA256 with the secret key, XChaCha20-Poly1305 over 33 bytes, 344 bytes in all.
- Records and revisionsMessagePack, zlib once, HPKE base mode, Ed25519 over the exact bytes, SHA-256 revision ids.
- The sync serverDetached lock signature, pinned key, exact bytes, cursor compare-and-advance.
- What stays visibleIdentifiers, parents, epoch, sizes and timing. Nothing readable.