How Skelett protects your data

01From master password to vault key

When you create your vault, Skelett generates a random 32-byte salt and stretches your master password through PBKDF2-SHA256 with 310,000 iterations into a 256-bit AES key. The password itself is never written anywhere — not on disk, not in the keychain, not over the network.

To check future unlocks, Skelett stores only a one-way verifier: the SHA-256 hash of the derived key. Even someone who reads it out of the keychain can't reverse it into your key or your password — the cheapest attack it allows is guessing passwords one by one, each guess costing a full 310,000-round derivation.

02What gets encrypted

Everything sensitive, field by field, before it touches disk: passwords, passkey private keys, 2FA secrets, card numbers and CVVs, identity details, secure notes, and attachment files. Each encryption uses AES-256-GCM with a fresh random nonce, so identical values never produce identical ciphertext, and any tampering fails authentication loudly.

Details that aren't secrets — item titles, usernames, site URLs — stay searchable so the app is usable while locked-at-rest. Your secrets never are.

03The key's life

• The vault key exists only in memory, and only while the vault is unlocked.
• Locking — manually, by auto-lock timer, or immediately on backgrounding if you choose — wipes it.
• A privacy shield covers the app in the iOS app switcher, so revealed passwords never land in system snapshots.

04Face ID, precisely

If you enable biometric unlock, the derived key is stored in a keychain item gated by biometryCurrentSet and WhenPasscodeSetThisDeviceOnly — meaning: this device only, never synced, and invalidated automatically if the device's biometric enrollment changes. Turning the toggle off deletes that key immediately. Your biometric data itself lives in the Secure Enclave; Skelett never sees it.

05Sync without a company cloud

Skelett syncs through the CloudKit private database of your own Apple ID. What leaves the device is ciphertext — the records are sealed with your vault key before they go anywhere. We operate no servers, so there is no Skelett database to breach, no employee who could peek, and nothing to hand over.

The salt and verifier travel via iCloud Keychain, so a new iPhone needs exactly two things: your iCloud sign-in, and your master password. If you enable Apple's Advanced Data Protection, your iCloud layer becomes end-to-end encrypted too.

06AutoFill, without leaks

• The AutoFill extension refuses to serve anything until you unlock — Face ID or master password, every time the system spins it up.
• What iOS's QuickType index holds is only site + username, never secrets.
• Credential matching is anchored to real host boundaries, so a credential saved for github.com is offered on gist.github.com — and not on github.com.evil.net.

07Small things that add up

• Clipboard: copies are marked local-only (no Universal Clipboard hand-off) and expire on a timer enforced by iOS itself, even if the app is closed.
• Site icons are drawn on-device. No favicon service ever learns which sites you store.
• Password generator draws from the system CSPRNG with rejection sampling — uniform characters, no modulo bias, at least one character from every class you enable.
• Analytics, if you leave it on, is anonymous usage counts only — see the privacy policy. One switch turns it off.

08What Skelett can't protect you from

Honesty section. No password manager can save you from everything:

• A weak master password. If someone compromises your iCloud account, the encrypted records plus 310,000-round PBKDF2 are the only wall left — and its height is your password. Make it long. A passphrase of several random words is ideal.
• A compromised device. Malware or a jailbreak on the phone you type into can defeat any app's encryption.
• Forgetting your master password. There is no recovery — by design, nobody (including us) can reset it. Skelett offers to erase and start over; the old vault stays unreadable forever.