Back to browse
AbsentKey E2E encrypted vault that releases secrets when you can't

AbsentKey E2E encrypted vault that releases secrets when you can't

by artidokuz·Mar 18, 2026·3 points·3 comments

AI Analysis

●●●BangerSolve My ProblemZero to OneCozy

Timer starts when someone requests access — no false positives from vacation check-in failures.

Strengths
  • Request-based trigger eliminates false positives from periodic alive-check systems
  • Different timeouts per person per secret — wife gets 3 days, partner gets 30
  • Source-available mobile client with E2E encryption before data leaves device
Weaknesses
  • 1Password and Bitwarden offer emergency access features within existing password managers
  • Requires trusted contacts to also install the app to receive secrets
Category
Target Audience

Anyone needing emergency access to passwords and documents for family or colleagues

Similar To

1Password Emergency Access · Bitwarden Emergency Access · Dead Man's Switch

Post Description

My wife doesn't know any of my passwords. If something happened to me tomorrow she'd be locked out of everything, wouldn't know where to find important documents either. I looked at dead man's switch apps and they all wanted me to check in every few days or weeks to prove I'm alive. Miss one check-in and everything gets released, you leak secrets because you were on vacation. Also I really hate unnecessary notifications.

So I built something different. In AbsentKey, you share your files/secrets then nothing happens until someone requests access. When they do, I get a notification and can approve or deny. If I don't respond within the timeout I set for that person, they get access automatically. The timer only starts when someone actively asks. No check-ins, no heartbeats.

You can set different timeouts per person per secret. My wife gets 3 days. My business partner gets 30. Whatever makes sense.

On the crypto side: everything is encrypted on the phone before it goes anywhere. 12-word BIP39 mnemonic, HKDF-SHA256 into an X25519 keypair via libsodium. Content gets a random 32-byte key, encrypted with XSalsa20-Poly1305. That content key is sealed to the owner's public key with crypto_box_seal. When you add a recipient, the content key gets re-encrypted to their public key via crypto_box_easy so the server stores sealed keys for both parties but can't open either. On approval or timeout, the recipient's app unseals locally.

Private key stays in iOS Keychain / Android Keystore. Server stores the public key and a BLAKE2b-256 hash of the private key (for detecting rotation, one-way).

What the server actually has: public keys, one-way hashes, encrypted blobs in R2, and sealed content keys it can't decrypt. One thing worth mentioning secret titles are in plaintext so you can browse your list without decrypting. The content is encrypted, the label isn't. It's a UX trade-off I'm still thinking about but I made it optional for this case.

The mobile client is source-available on GitHub. Not open source the license is inspect-and-verify, not fork-and-compete. Backend is closed. But you can read every line of crypto, every API call, every byte that leaves the phone. That's the point: don't trust my claims, read the code.

This is not a password manager. Bitwarden handles your access to your stuff. This handles someone else's access to your stuff.

Stack: Cloudflare Workers + Hono + D1 + R2, React Native/Expo, Astro. Crypto via react-native-libsodium and @noble/hashes.

Similar Projects

Security●●Solid

AxKeyStore – Zero-trust CLI secrets manager using your own GitHub repo

GitHub-as-untrusted-storage with XChaCha20 is clever, but 1Password and Vault already own secrets.

Niche GemShip It
robin_a_p
213mo ago