Skip to main content
Security

Is AbsentKey Safe? Security Explained

AbsentKey can't read your passwords. Not 'won't.' Can't. How zero-knowledge encryption and request-based access keep your secrets safe.

A locked vault with a transparent server behind it showing only scrambled data
Illustration · AbsentKey editorial FIG. 01

AbsentKey uses zero-knowledge encryption. Your secrets get encrypted on your phone before they leave it. Our servers only ever store scrambled data they cannot decrypt. Even if someone broke into every server we have, they would walk away with nothing readable.

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. The encryption keys come from your 12-word recovery phrase, which is generated on your phone and never sent to our servers. We don’t have the keys. We can’t derive them. We can’t guess them.

Our servers store encrypted blobs. That’s it. 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.

This isn’t new or experimental cryptography. XSalsa20-Poly1305 comes from the NaCl/libsodium family, the same library Signal relies on. The 12-word phrase uses HKDF-SHA256 for key derivation, a NIST-recommended standard.

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. The architecture makes spying impossible, not just against policy.

What does “zero-knowledge” mean in practice?

Zero-knowledge means AbsentKey has zero knowledge of your data. We can’t read it, search it, analyze it, or hand it over to anyone. Not to governments. Not to advertisers. Not to our own employees. The server sees encrypted gibberish and metadata about access control (who can request what, what timers are set). Nothing else.

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.

If we're breached, there's nothing worth stealing your secrets were never readable on our servers.
Is AbsentKey Safe? Security Explained

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. Zero-knowledge removes that risk entirely.

With AbsentKey, a breach of our servers produces nothing useful. An attacker gets encrypted blobs. Without the keys that exist only on your device, those blobs are computationally useless. Not hard to crack. Useless.

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 blobs they can’t decrypt (no keys on the server)
  • Access control metadata (who can request what, timer durations)
  • Public keys (designed to be public, useless for attacks)
  • 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.

Cost of a breach

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, a server compromise still produces nothing readable.

65% of consumers say they immediately lose trust in a brand after a breach (SQ Magazine, 2026). We built AbsentKey so that even if we’re breached, there’s nothing worth stealing. Your secrets stay safe because they were never on the server in readable form to begin with.

At a service where the company holds encryption keys, a breach means your data is readable. With AbsentKey, a breach is embarrassing for us but harmless to you.

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:

  1. You get a push notification.
  2. You can approve, deny, or just wait.
  3. If you don’t respond, the timer you set runs down.
  4. Only when the timer expires does the recipient get in.

So a stolen phone doesn’t automatically expose shared secrets. The thief would need to request access, which sends a notification to you. You see it. You deny it. Done.

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 with someone, AbsentKey uses X25519 key exchange (Diffie-Hellman on Curve25519). In plain terms: your device and the recipient’s device do math together to agree on a shared encryption key. Neither device sends its private key over the network. The server relays the messages but never learns the shared key.

Same approach Signal uses for messaging. Two devices work out a shared secret through math. The server in the middle carries encrypted packets and has no idea what’s inside.

encrypt-and-upload

Plaintext stays on the device. Only ciphertext leaves.

const key = derive(recoveryPhrase) // stays local const cipher = xsalsa20Poly1305.encrypt(secret, key) upload( cipher) “server stores ciphertext”

Your secret gets encrypted with a key that only exists on two devices: yours and the recipient’s. Our servers are just the delivery system. They carry the package but can’t open it.

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 plaintext never hits the network. Confirm that keys stay on-device.

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 encryption primitives (XSalsa20-Poly1305, X25519, HKDF-SHA256) all come from libsodium, one of the most audited cryptographic libraries around. We didn’t roll our own crypto. We used the same building blocks the security community has reviewed for years.

What we don’t do

Sometimes it helps to be specific about what a service doesn’t do.

We don’t hold your encryption keys. They’re derived from your 12-word phrase on your device. 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. 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). People don’t trust companies with their data. Honestly? They shouldn’t have to. Zero-knowledge architecture makes trust optional. You don’t need to trust AbsentKey. The math handles it.

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 only handle encrypted blobs in between. 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.

Can law enforcement force AbsentKey to hand over my data?

They can request it, and we’d comply with valid legal orders. But what we’d hand over is encrypted blobs. The same unreadable data that sits on our servers. Without your 12-word recovery phrase, that data is useless. We can’t decrypt it. No one at AbsentKey can. A 2026 USENIX Security paper examined zero-knowledge claims of major password managers with over 60 million combined users, confirming that proper zero-knowledge design makes server-side decryption impossible.

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 everything 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, but the security model doesn’t require trusting the server. That’s the whole point of zero-knowledge: even a compromised server can’t read your data.

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 was built so you don’t have to trust us. Your secrets are encrypted on your phone with keys that never leave your phone. The server is a delivery system, not a vault. Nobody at AbsentKey can read what you share. Not today, not ever.

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.

AbsentKey
Editorial · Product

Posts from the AbsentKey team on encryption, inheritance, and the soft edges of digital privacy. AbsentKey is a free vault for your secrets: open-source client, end-to-end encryption, no cloud account required.