Keys are made on your devices. The server only ever holds ciphertext.
This page covers what Hisar protects, what a server operator can see, and where the limits are. The complete design, with every protocol detail, is in docs/DESIGN.md.
- 1On your deviceMaster password + 128-bit Secret Key → Argon2id and HKDF → your account unlock key. It decrypts your keyset: a symmetric key, a hybrid post-quantum key pair and a signing key.
- 2On the wireTLS, and sign-in with OPAQUE: the server never receives your password, or anything it could guess it from without the Secret Key.
- 3On your serverEncrypted items, vault keys wrapped to each member, and the metadata below. No key that opens any of it.
What the server sees
So does anyone who runs it, backs it up or breaks into it.
- Account emails, and the emails people invite or share with
- Which accounts can open which vaults
- How many items a vault has, their sizes and when they change
- Devices, IP addresses and app versions
- For share links: who made one, its size, expiry, view limit, views, and the IPs that open it
What it never sees
These are encrypted before they leave your device.
- Passwords, notes, one-time code seeds, SSH private keys
- Item titles, URLs and vault names
- Master passwords and Secret Keys
- The key in a share link (it stays after the
#) - What you approved or denied on your iPhone
Cryptography
| Purpose | Primitive |
|---|---|
| Password stretching | Argon2id, 64 MiB, parameters checked by the client |
| Key derivation | HKDF-SHA256 |
| Items | XChaCha20-Poly1305 |
| Vault keys between people and devices | HPKE (RFC 9180), hybrid ML-KEM-768 + X25519 |
| Sign-in | OPAQUE (RFC 9807), ristretto255 |
| Signatures (approvals, keysets) | Ed25519 |
| Share links, decrypted in the browser | AES-256-GCM, PBKDF2 for the passphrase |
The hybrid KEM stays secure as long as either half holds, so recorded traffic and database copies stay protected against a future quantum computer.
Threat model
| If someone… | What happens |
|---|---|
| Copies the server's database or a backup | They get ciphertext and metadata. Guessing a password offline is impossible without that user's Secret Key. |
| Controls the server, including its operator | They can withhold or delay sync and approvals, and see the metadata above. They can't read items, forge an approval or weaken password stretching. |
| Watches the network | TLS and OPAQUE: nothing to learn, no one to impersonate. |
| Runs code on your unlocked Mac | Out of scope for any password manager. Hisar narrows it: every key use asks and names the app, and unsigned programs are flagged. |
| Is a coding agent you approved | It only sees vaults you made available to agents. A command you approve has real values and could leak them; masking hides values in output, it isn't a sandbox. |
| Steals your iPhone | It needs Face ID to approve, and an approval never unlocks your Mac. |
No recovery, by design
No one can reset a master password or show a Secret Key, server operators included. Print the Emergency Kit and keep a second device signed in.
Audits
Hisar has not had an independent audit yet. Reviews of the design document are welcome as issues.
Report a vulnerability
Email support@tryhisar.com or use GitHub's private vulnerability reporting, not a public issue. We reply within two working days and credit reporters who want it.