ZZPass uses zero-knowledge, end-to-end encryption. Your data is encrypted on your device before it goes anywhere. We can't read it. Apple can't read it. Nobody can, except you.
Four cryptographic guarantees, applied at every layer of the system. The rest of this page is the technical detail behind each one.
We never see your passwords. All encryption happens on your device, with keys we never receive.
Every credential, note, and attachment is AES-256-GCM encrypted in your vault.
Data is encrypted before it reaches iCloud. CloudKit only ever sees ciphertext.
Shared items use end-to-end ECIES encryption. Only invited members can decrypt.
When you create your ZZPass account, your primary password is transformed into a 256-bit encryption key using an intentionally slow process that makes brute-force attacks impractical. This key encrypts and decrypts everything in your vault. It never leaves your device. We never see it.
| Algorithm | PBKDF2-SHA256 |
| Iterations | 650,000 |
| Salt | 128-bit · SecRandomCopyBytes |
| Output | 256-bit symmetric key |
| Storage | Device Keychain only |
| Comparison | Constant-time SHA-256 hash |
OWASP recommends at least 600,000 PBKDF2-SHA256 iterations. ZZPass uses 650,000.
Every password, username, note, TOTP secret, and attachment in your vault is encrypted with AES-256-GCM before being stored. Both confidentiality and integrity, nobody can read it, nobody can tamper with it undetected.
ZZPass uses Apple's CloudKit for sync, your vault never reaches a ZZPass server. Sensitive data is encrypted at the application layer; CloudKit only stores and transports ciphertext.
Trust model: Even if iCloud were compromised, your vault would remain encrypted. The decryption key exists only on your devices, never in transit, never in the cloud, never on our servers.
Encryption is foundational, but a vault is only as safe as the device unlocking it. ZZPass stacks five layers of defense before your data is ever decrypted.
Re-keying the entire vault is a delicate operation. ZZPass's migration is atomic, fault-tolerant, and never leaves data unrecoverable, even if something goes wrong mid-flight.
Safety net. If the process is interrupted (crash, power loss), ZZPass keeps the backup key so no data is ever lost. Items encrypted with either key decrypt transparently until the migration completes.
Your Secret Key is a human-readable encoding of your encryption salt. It is one of two halves: together with your primary password it restores your vault on a new device, and on its own it opens nothing. That is what makes it safe to print and keep. Forgotten the password rather than lost the device? Biometric recovery is the route back.
| Format | Z1-XXXX-XXXX-XXXX-XXXX |
| Encodes | 128-bit random salt |
| Pairs with | Your primary password |
| On its own | Opens nothing |
| Changes | Only if you ask, when changing your password |
| Stored on ZZPass servers | Never |
Biometric recovery. If you enable it, you can reset your primary password with Face ID or Touch ID on a trusted device, recovery stays entirely on hardware you already control. ZZPass still can't reset it for you, and never gains access to your vault.
For technical evaluators, every algorithm, key size, and standard ZZPass relies on. No custom cryptography, no third-party libraries.
This isn't a policy.
It's math.
Without your master key, your data is indistinguishable from random noise.
Every security architecture has a boundary. Here's what ZZPass defends, and what remains your responsibility as the device owner.
TimeCapsule and Emergency Access both need a key to reach someone at a future moment. Both are built on one primitive: a server-enforced deadline on keys that are already sealed to their recipients.
The escrow stores only key blobs already encrypted to the recipients' public keys, plus a release time. It returns opaque ciphertext after the deadline and never sees plaintext.
user_id = SHA-256(P-256 public key). There is no account registry to squat and no external identity provider. Only the holder of the matching private key can mint an access token, via a signed possession proof.
Release timing can't be spoofed by a client changing its own clock.
Recipients verify a deposit's signature against the pinned group-owner key before adopting a released key ring, defeating malicious-member, server, and MITM ring substitution.
For the dead-man's-switch case, arming a release can email you a signed link to halt or extend it, so you can stop an unwanted release without your primary device.
Unknown and unauthorized capsule ids return an identical 404, and every retrieval attempt is logged. Tokens are HMAC-SHA256, verified in constant time.
ZZPass collects a small amount of product telemetry. The ingest server is open source, so these claims are verifiable rather than promised.
Our server components are published as standalone MIT-licensed repositories, so anyone can audit exactly what runs.
The zero-knowledge time-lock and dead-man's-switch key escrow behind TimeCapsule and Emergency Access.
The anonymous telemetry ingest server.
The uptime monitor.
The client cryptographic core and browser extension are on the open-source roadmap. All cryptography uses Apple CryptoKit and CommonCrypto, no bespoke algorithms.
We welcome reports from security researchers and treat them as a priority. Please tell us before disclosing publicly.
Email security@zzpass.com. Please don't open a public GitHub issue for a vulnerability.
Include the affected component and version, a description, steps to reproduce, and the impact you believe it has. We're especially interested in anything touching cryptography, key handling, the sharing or escrow protocols, or autofill.
We will not pursue or support legal action against researchers who make a good-faith effort to follow this policy, avoid privacy violations and service degradation, access only their own accounts and data, and give us reasonable time to remediate before disclosing. Activity conducted consistently with this policy is authorized: we consider it lawful, helpful, and appreciated.
In scope: the ZZPass iOS and macOS apps, the open-source server components, and zzpass.com and its subdomains. Out of scope without demonstrated impact: denial-of-service and rate-limit exhaustion, social engineering or physical attacks, automated scanner output without a proof-of-concept, missing best-practice hardening, third-party service vulnerabilities, self-XSS, and anything requiring an already-compromised or jailbroken device.
RELATED HELPEmergency guideAccount recoveryEmergency Kit helpAbout ZZPass
Download ZZPass and take control of your digital security.
ALL CRYPTOGRAPHY IMPLEMENTED USING APPLE CRYPTOKIT · NO THIRD-PARTY DEPENDENCIES · NOTHING LEAVES YOUR DEVICE UNENCRYPTED · NO COMPROMISES
