AbsentKey uses zero-knowledge encryption. Your secrets get encrypted on your phone before they leave it. Our servers cannot decrypt secrets. Server security still matters for availability and access rules. Plenty of secrets never even leave your phone: the vault works offline with no account, so your data starts, and can stay, entirely on your device.
Can AbsentKey see your passwords?
No. And that’s not a policy. It’s math.
When you create a secret in AbsentKey, the app encrypts it on your device using XSalsa20-Poly1305 before anything gets uploaded. Each secret gets a fresh random 32-byte content key and a random 24-byte nonce. The app seals that content key to your X25519 public key. Your keypair is derived from your 12-word recovery phrase, which is generated on your phone and never sent to our servers.
Our servers store encrypted secrets and encrypted content keys. Think of it like handing someone a locked safe without giving them the combination. They can hold the safe, move it around, keep it in a warehouse. They just can’t open it.
AbsentKey uses libsodium for XSalsa20-Poly1305 encryption and X25519 key operations. HKDF-SHA256, implemented with @noble/hashes, derives the keypair from the entropy encoded in your BIP39 recovery phrase.
Here’s the thing though: 76% of Americans say encryption matters when choosing apps, according to a Proton survey from 2025. But 41% of those same people thought Gmail was end-to-end encrypted. It isn’t. That gap between what people assume and what’s actually happening is wide. AbsentKey doesn’t leave room for assumptions. Secrets are encrypted before upload, and our servers do not hold the private keys needed to decrypt them.
What does “zero-knowledge” mean in practice?
Zero-knowledge means AbsentKey cannot decrypt your secrets. The server stores encrypted content and content keys, plus public keys and access control metadata (who can request what, what timers are set). We can provide stored records in response to a valid legal order, but we cannot turn encrypted secrets into plaintext.
Most cloud services encrypt your data “at rest” and “in transit.” Sounds secure, right? But the company holds the encryption keys. They can decrypt everything whenever they want. Their employees with database access can too. And if an attacker compromises their key infrastructure, every piece of data in the system is exposed at once.
Your secrets are encrypted before upload. Our servers do not hold the private keys to decrypt them.
The global average cost of a data breach hit $4.44 million in 2025 (IBM, 2025). Human factors were involved in 60% of breaches, according to Verizon’s DBIR. A single compromised employee at a company that holds encryption keys can unlock everything. Keeping private keys off the server limits what a stolen database can reveal about secrets.
Stolen AbsentKey server data does not include the private keys needed to decrypt secrets.
What if our servers get hacked?
This is the question worth asking. Every company says “we take security seriously.” Most of them also hold the keys to your data, which means a breach exposes everything.
If someone compromised every AbsentKey server, here’s what they’d walk away with:
- Encrypted secrets and encrypted content keys, without the private keys needed to decrypt them
- Access control metadata (who can request what, timer durations)
- Public keys used for encryption and sharing
- Email addresses tied to accounts
What they wouldn’t get: your passwords, your crypto seed phrases, your private files. None of that exists on our servers in readable form. It never has.
The global average cost of a data breach hit $4.44 million in 2025. Human factors were involved in 60% of breaches. With zero-knowledge architecture, stolen server data does not include private keys needed to decrypt secrets.
65% of consumers say they immediately lose trust in a brand after a breach (SQ Magazine, 2026). AbsentKey encrypts secrets before upload and keeps private keys off the server. That protects content in a stolen database, but does not make a breach harmless.
At a service where the company holds encryption keys, a breach means your data is readable. AbsentKey’s servers cannot decrypt secrets. A breach could still disrupt access or affect server access rules.
How does request-based access protect you?
Encryption handles the “can the server read my stuff?” problem. But when it comes to password inheritance, there’s another angle most people don’t think about: what if someone gets hold of a recipient’s phone?
Most password sharing tools give recipients immediate access the moment you share. Phone gets stolen? Account compromised? The attacker sees everything.
AbsentKey works differently. You set a waiting time for each person you share with, anywhere from instant to 365 days. Unless you chose instant, recipients have to request access first. When they do:
- You get a push notification.
- You can approve, deny, or just wait.
- If you don’t respond, the timer you set runs down.
- The server grants access after approval or when the timer expires.
These are server access rules, not a cryptographic timelock. Once someone has decrypted a secret, revoking access cannot erase copies they saved.
For a secret with no access granted yet, a thief would need to request access, which notifies you. You can deny it before the timer expires. Secrets already accessible on that device still depend on its security.
94% of passwords are reused across two or more accounts, according to Verizon’s 2025 report. If someone cracks one account and uses those credentials to get into a sharing service, request-based access is another wall between them and your data. Encryption protects the contents. Access control protects the door.
How does sharing work without exposing secrets?
When you share a secret, the app wraps its content key using the recipient’s X25519 public key and your private key through libsodium’s crypto_box_easy. The recipient unwraps that key on their device and uses it to decrypt the content. Neither private key is sent over the network.
The server stores the encrypted content and wrapped key and controls when the recipient can download them. It cannot decrypt your secrets.
# Secrets are encrypted before upload. const key = randomBytes(32) // fresh content key const cipher = xsalsa20Poly1305.encrypt(secret, key, randomNonce) upload( cipher, seal(key, ownerPublicKey)) → “server stores encrypted content and sealed key”
Your secret gets encrypted with its own random content key. The server can store sealed or wrapped copies of that key, but the private keys needed to open those copies stay on the owner’s and recipients’ devices.
Even intercepting the encrypted payload in transit gives an attacker the same thing as breaching the server: unreadable data. The encryption doesn’t care how you got the blob. Without the key, it’s noise.
You can check the code yourself
AbsentKey’s mobile client is source-available on GitHub. You don’t have to take our word for any of this. Read the encryption implementation. Verify that secrets are encrypted before upload. Confirm that private keys and recovery phrases stay off the server.
53% of consumers are more likely to trust brands with transparent practices, according to CompareCheapSSL’s 2025 data. But we’re not asking for trust. We’re saying: here’s the code, check it yourself.
The app uses libsodium’s crypto_secretbox_easy for content encryption, crypto_box_seal for the owner’s content-key copy, and crypto_box_easy for sharing. HKDF-SHA256 comes from @noble/hashes.
What we don’t do
Sometimes it helps to be specific about what a service doesn’t do.
We don’t hold your private key or recovery phrase. Your keypair comes from the phrase, while each secret gets a random content key. The private key is stored with Expo SecureStore and used in app memory after unlock. Biometrics or your device PIN unlocks the app; it does not derive the key. We don’t have a “forgot password” backdoor. Lose your recovery phrase and your device, and your data is gone. That’s the trade-off of real zero-knowledge. We can’t scan your secrets because they’re encrypted. We don’t require daily check-ins or “prove you’re alive” pings. We don’t make you create an account, or even go online, to get started: the vault works offline and your secrets stay encrypted on your phone from the first one you save, so nothing reaches our servers unless you choose to back it up or share it. And we don’t charge recipients. Receiving is free. Always.
The Thales 2025 Consumer Digital Trust Index surveyed over 14,000 consumers across 14 countries. Not a single sector scored above 50% in data trust (Thales, 2025). AbsentKey keeps the private keys needed to read secrets off the server. You still rely on the service for availability and access rules.
FAQ
Is AbsentKey really end-to-end encrypted?
Yes. Encryption happens on your device before data is uploaded. Decryption happens on the recipient’s device after download. Our servers store encrypted secrets and encrypted content keys. They do not hold the private keys needed to decrypt them. The encryption uses XSalsa20-Poly1305 from the libsodium library, and key exchange uses X25519. Both are well-audited. You can verify this in the source-available mobile client on GitHub.
What happens if I lose my recovery phrase?
If you lose your 12-word recovery phrase and also lose access to your device, your secrets are permanently locked. AbsentKey can’t recover them. That’s the trade-off of zero-knowledge encryption: the service that can’t see your data also can’t restore it. Write your recovery phrase down and store it somewhere safe, separate from your phone. Restoring also requires an available encrypted backup or copy of the data; the phrase cannot recreate lost local files.
Can law enforcement force AbsentKey to hand over my data?
They can request it, and we’d comply with valid legal orders. We could provide stored records, including encrypted secrets and encrypted content keys. We do not hold your private key or recovery phrase and cannot decrypt secrets. You can inspect AbsentKey’s encryption implementation in the mobile client source.
How is AbsentKey different from sharing passwords over text?
Text messages are unencrypted. Your carrier, your phone manufacturer, and anyone intercepting the signal can read them. 81% of confirmed breaches involve weak, reused, or stolen passwords (Astra). Sharing passwords in plaintext makes a bad situation worse. AbsentKey encrypts secrets end-to-end, adds request-based access control, and lets you revoke access at any time. A text message gives you none of that.
Is AbsentKey open source?
The mobile client is source-available on GitHub. “Source-available” means you can read and audit the code, but it’s not a permissive open-source license. You can verify every encryption claim we make by reading the implementation. The server-side code isn’t published. Stored encrypted content cannot be decrypted with server data alone, though approval and waiting periods depend on server access controls.
Your secrets, your keys
The security industry has a trust problem. Companies say “we’re secure” while holding the keys to everything you store. Trust in big tech dropped by 6 percentage points year over year in a 2025 survey (SQ Magazine, 2026). And 64% of consumers said they’d switch to brands with stronger data protections.
AbsentKey encrypts secrets on your phone. Encrypted content keys can be uploaded for sync and sharing, while your private key and recovery phrase stay off the server. Nobody at AbsentKey has the private keys needed to read that content.
If you’re going to share passwords, crypto keys, or private files with people you trust as part of your digital legacy plan, the service carrying those secrets shouldn’t be able to read them. AbsentKey can’t. That’s not marketing. That’s architecture.
Download AbsentKey. Free to receive. Available on iOS and Android.
