How Sifrvault protects your vault

The starting point: we have nothing

• There is no Sifrvault server and no account with us. Your vault lives in the private database of your own iCloud (CloudKit).
• Everything is encrypted on your device before it goes to iCloud. Apple only sees encrypted data; we see nothing at all.
• No third-party analytics, ads, trackers or crash reporting, not in the app and not on this website.
• So we can’t view, recover or hand over your vault, not even if someone asks us to.

Keys

1. Your master password is Unicode-normalized on your device and turned into a key-encryption key with PBKDF2-HMAC-SHA256 (600,000 rounds, as OWASP recommends) and a random 32-byte salt. The master password itself is never stored; every change gets a new salt.
2. That key wraps the vault key: 256 random bits, created on your device, which only leaves the device wrapped.
3. The vault key encrypts each item and each document separately with AES-256-GCM.
4. The recovery key (120 random bits, 24 characters) wraps the same vault key through HKDF-SHA256. Only the wrapped result is in iCloud; you see the recovery key itself once, on screen and in the emergency kit.

The key derivation algorithm is stored as a version number in the vault header. A vault with older settings is upgraded automatically after unlocking, so we can later move to, for example, Argon2id. What comes from iCloud is bounded (100,000 to 10,000,000 rounds, at most five vault headers), so manipulated data can’t make the app hang.

Master password requirements

Anyone who steals the encrypted vault from iCloud can try passwords offline. That’s why Sifrvault refuses weak master passwords. Allowed is a sentence of at least 16 characters (for example four words), or at least 12 characters with at least three kinds of characters and no common word or frequently used password.

Encrypting the contents

• AES-256-GCM through Apple CryptoKit, with a new random nonce for every encryption.
• The authentication tag is always checked: modified or damaged data is refused, never half read.
• Each item is bound to its own ID and each document to its own ID. So encrypted blocks can’t be swapped unnoticed.
• Each item is one encrypted block: name, websites, usernames, passwords, notes, folders, 2FA keys, recovery codes, passkeys, IBAN, PINs and SSH and API keys.

What’s readable in iCloud?

Only what’s needed to sync: the number of items, random IDs, modification times, document sizes, the salt, the number of rounds, the key derivation version, a non-secret fingerprint of the vault key and the date of the recovery key. Nothing about the contents can be derived from that.

On your device

• Face ID and Touch ID: the vault key is in this device’s keychain. It never goes to iCloud, disappears when you turn off your device passcode and becomes invalid when a face or finger is added.
• IBANs and PINs stay hidden even in an open vault and only appear after an extra Face ID or Touch ID check.
• Auto-lock after a set time; on the Mac also on sleep and screen lock. On iPhone and iPad the app is covered in the app switcher.
• AutoFill uses a copy with only encrypted data and only opens it after Face ID, Touch ID or your master password. Sifrvault only passes websites and usernames to the system, never passwords.
• Viewed documents are temporarily decrypted in a protected folder and erased on closing, locking and launch.

Clipboard and screen

• Copied secrets stay on the device (not through Universal Clipboard) and are cleared after the set time, on the Mac also when you quit the app.
• On the Mac they’re marked so clipboard managers don’t keep them in their history.
• On the Mac a window with a visible password, PIN or IBAN is excluded from screenshots, screen recordings and screen sharing.

Passkeys

• Sifrvault creates passkeys as a P-256 key pair (ES256) with Apple CryptoKit. The private key is stored in the item and so is stored and synced encrypted, just like a password.
• A website only gets the public key. A signature to sign in is only produced after Face ID, Touch ID or your master password.
• A passkey you create while the app is closed waits on the device, encrypted with your vault key, until Sifrvault puts it in your vault. Passkeys never go into the password history.

Transferring between apps

• Transfers use the iOS and macOS 26 feature (based on the FIDO standard for exchanging credentials): encrypted and directly from app to app, without a file and without us in between.
• Sending your whole vault to another app requires Face ID, Touch ID or your device passcode.
• What Sifrvault receives only goes into your vault once it’s open, and is then stored encrypted like everything else.

Browser extension (Chrome, Edge, Brave on the Mac)

• The extension only talks to the Sifrvault app on the same Mac, through a small signed helper. Nothing goes over the network.
• The helper only works when Chrome, Edge or Brave starts it; it checks the browser’s digital signature. The app in turn checks the helper’s signature.
• A web page only gets logins that belong to that website, and only while your vault is open.

SSH agent and sifr (Mac, for developers)

• Both are off by default. You turn them on in Settings › Developer.
• With the SSH agent, ssh and git use the SSH keys in your vault. Your private key never leaves the app: ssh only gets a signature.
• For every signature, Sifrvault asks for Touch ID or your Mac password. The window shows which key and which program is asking.
• Only your user on this Mac can reach the agent. So that ssh knows which keys exist even when your vault is locked, the Mac remembers the public keys, without names. They don’t go to iCloud.
• With sifr you get passwords, tokens and 2FA codes in Terminal. Only the sifr program inside the app, with our digital signature, may talk to the app; other programs are refused. Here too, Sifrvault asks for Touch ID every time.

Backups and export

An encrypted backup uses AES-256-GCM with a key from a password you choose yourself; without that password the file is unreadable. An unencrypted export (JSON) is meant for switching; the app warns that the file is readable.

What Sifrvault protects against

• A leak or breach at Apple or in your iCloud account: the attacker only gets encrypted data and has to guess your master password.
• A stolen or lost device that is locked.
• Snooping through Universal Clipboard, clipboard managers, screen recordings and screen sharing.
• Other programs on your Mac pretending to be a browser to request passwords.
• Forged or swapped data in iCloud: it’s refused.

What it doesn’t protect against

• A device that’s already compromised, for example by malware with administrator rights or a keylogger. While your vault is open, such software can look along.
• A weak or reused master password, combined with access to your iCloud data.
• Someone with your unlocked device and your face or finger. On a trusted device, Face ID or Touch ID can also set a new master password; that’s deliberate.
• An emergency kit in the same iCloud account as your vault. Better to print the emergency kit.
• Restoring an older version of an item by someone who can write to your iCloud account. Forged content isn’t possible; a genuine older version is. The impact is limited: an older password comes back, which is also in the history.

Known limitations

• PBKDF2 isn’t memory-hard; Argon2id would make guessing on graphics cards more expensive. Switching later is possible without breaking existing vaults.
• There’s no external audit or pentest yet, but there is an internal review of all cryptography and key storage and automated tests. An independent review is planned.
• Sifrvault and its maker are not certified under ISO 27001, NEN 7510 or similar standards.
• For organizations: there’s no central management, no audit log and no shared vault, and the vault lives in a personal iCloud.

Report a vulnerability

Found a security problem? Email [email protected] with “Security” in the subject, and describe what you found and how to reproduce it.

• You’ll get a response within five working days.
• Only disclose the problem once there’s a fix, or after 90 days, whichever comes first.
• Only test with your own vault and your own devices. There’s no server to test.
• If you report a problem responsibly, we’re happy to credit you with the fix, if you like.

See also the privacy policy.