4 ms·
Show HN: AbsentKey E2E encrypted vault that releases secrets when you can't
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.
- umeridrisi 7mo agoGreat thing.
- alcazar 7mo agoThis is an interesting approach. You're right that normal dead man's switches create unnecessary notifications. By definition, every check-in you acknowledge is unnecessary. Only the last one, when you're actually dead, is necessary. So you invert it: from push-based to pull-based. This creates a different set of issues. Now your partner or contacts must keep the app installed and set up over the years. They will change phones, life will happen. But if they don't properly custody their keys, they won't be able to access the data when they need it most. There's an argument for both approaches, and neither is necessarily superior. When we built our dead man's switch, we were thinking of sending a last message to non-technical people who aren't good at long-term key custody. But if your recipients are more technical or you expect this to be needed in a short timeframe, this approach reduces notifications, which is a plus. By the way, kudos for your cryptographic choices and for making the app code source-available. The next step would be reproducible builds with instructions for manual builds from source. Otherwise, I can't be sure that what I'm installing matches the published codebase, which diminishes the value of sharing the code. What I'm curious about: how is this different from Bitwarden's Emergency Access? You can upload attachments to your vault and set different emergency contacts for different vaults. So if you're already using Bitwarden as your password manager, why not use its Emergency Access feature too?
- artidokuz 7mo agoGreat points, and you're right to call out the push vs. pull tradeoff neither is universally better, it really depends on your recipients. On the Bitwarden comparison though: one thing worth clarifying is that Bitwarden's emergency access doesn't actually support per-vault or per-item scoping. It's all-or-nothing your contact gets your entire personal vault, and you can't give different people access to different secrets. That's actually a long-standing feature request in their community with no resolution yet. One of the reasons I made this app. The bigger practical gap is the recipient side. Bitwarden emergency access requires your contact to have their own Bitwarden account, maintain it over the years, and know to go request access when something happens to you. For a technically savvy partner who already uses Bitwarden, sure that works. But for a parent, sibling, or lawyer who isn't in that world, it quietly fails in the exact moment it's needed most. If they know there is a spesific app for these cases, easy to use, a way to request not buried under 100 features I though this would be easier to use for them. Also they can request one secret from you at one time. Maybe a wifi password? It doesnt have to be life or death. This is what the app is about it deliveres secret whenever you want. Dead mans switch case is only one option. And fair point on reproducible builds that's a meaningful gap between source-available and truly verifiable. Worth prioritizing. I want to invest more time on that.
- deleted 7mo ago[deleted]