Security Overview
Built to be unreadableto everyone. Including us.
Your vault documents use encryption with keys controlled by you. They are encrypted on your device before they ever touch our servers. We hold encrypted document bodies that require your decryption keys. Optional Life Book composition is a separate, consented flow: selected written answers pass through our backend to Anthropic, and the resulting book is encrypted in your browser before storage.
Core principles
Three layers of protection,at every level of the stack.
Protection across the stack: browser encryption, controlled access, and integrity verification for encrypted archives.
Zero-Knowledge
Your vault passphrase derives a KEK via Argon2id. A separate Master Key encrypts per-file keys. Vault documents are encrypted before upload. Optional AI composition processes only the written answers you consent to send.
Contact One-Time Keys
Each trusted contact gets a unique 256-bit key generated on your device and delivered through the email flow. Their encrypted bundle remains unavailable until its release is authorized.
Trusted Delivery
Inactivity-based triggering with escalating warnings over weeks. Only after the final warning period expires are contact bundles activated. Any login resets the timer.
Encryption Architecture
Zero-knowledge by design,not by policy.
Zero-knowledge means the server is architecturally incapable of reading your data: not a policy choice, but a mathematical constraint.
Two-layer key derivation
Your password is run through Argon2id (64 MB memory, GPU-resistant) with a unique per-user salt to derive a KEK (Key Encryption Key). A separate 256-bit Master Key is randomly generated at registration and encrypted with the KEK. Neither key ever leaves your device.
Per-file encryption
Each file gets its own random 256-bit File Encryption Key (FEK). The file is encrypted with AES-256-GCM and a unique 12-byte IV. The GCM authentication tag ensures ciphertext integrity: any tampering is detected on decryption.
Envelope key wrapping
Each per-file FEK is encrypted with your Master Key using AES-256-GCM. The encrypted FEK (EFEK) is stored server-side alongside the ciphertext. Only your device can decrypt the Master Key and therefore unwrap any FEK.
Transport security
All data in transit is protected by TLS 1.3 with forward secrecy. Large file uploads bypass edge functions entirely via signed URLs so encrypted bytes go directly to storage, minimising the attack surface.
// 1. Derive KEK from password (device-side only)
const kek = await argon2id({
password: userPassword,
salt: kdfSalt, // stored server-side (not secret)
memory: 65536, // 64 MiB, brute-force expensive
iterations: 3,
parallelism: 4,
hashLength: 32, // 256-bit KEK
})
// 2. Decrypt Master Key (MK was encrypted with KEK at registration)
const mk = await crypto.subtle.decrypt(
{ name: 'AES-GCM', iv: mkIv },
kek, encryptedMasterKey // EMK fetched from server
)
// 3. Per-file encryption
const fek = crypto.getRandomValues(new Uint8Array(32))
const iv = crypto.getRandomValues(new Uint8Array(12))
const cipher = await crypto.subtle.encrypt(
{ name: 'AES-GCM', iv }, fek, plaintext
)
// 4. Wrap FEK with Master Key (AES-256-GCM)
const fekIv = crypto.getRandomValues(new Uint8Array(12))
const efek = await crypto.subtle.encrypt(
{ name: 'AES-GCM', iv: fekIv }, mk, fek
)
// Only { cipher, iv, efek, fekIv } are uploaded
// Server never sees: kek, mk, fek, plaintextImportant consequence
If you forget your password, your data cannot be recovered: not by you, not by us, not by any court order. The KEK derived from your password is the only way to unlock your Master Key. This is a feature, not a bug.
Encryption applies to memory too
Voice notes, video messages, dated journal entries, and the 1,000-prompt Life Story answers are all encrypted client-side under the same Master Key as your documents. The server cannot transcribe a recording, generate captions, or thumbnail a video. There is no analytics layer, no AI summarisation, no admin override. Journal · Life Story
Data at Rest & In Transit
What we store,and what we never see.
Edge function architecture
All business logic is routed through edge functions. There are no direct client-to-database connections, ever.
- All storage encrypted at rest (AES-256)
- No direct client-to-database connections
- All logic routed through edge functions
- Adapter pattern isolates infrastructure
- Migration-ready: swap adapters, zero logic rewrites
- Signed upload URLs bypass edge functions for large files
- Secrets stored in environment variables, never in code
Depth, Not Just Presence
Zero-knowledge is the floor.this is how it goes deeper.
Proton Pass, Bitwarden, 1Password, and Lastkey all describe themselves as zero-knowledge, that is table stakes for a privacy-first vault. The architectural difference is what each product does inside the trust boundary. Henedo combines six layers of in-boundary defence that no competitor ships together.
Eternal Vault Storage
Encrypted cloud archives,with a sealed integrity record.
The current Eternal Vault offer is $699 once for 100 GiB and a 100-year preservation term. After payment is confirmed, your purchase appears in the Eternal Vault dashboard. You upload encrypted content, choose your inheritors, and seal the archive. Encrypted objects are stored in Cloudflare R2.
What long-term preservation requires
Maintaining an archive over decades requires continuing operations and future migrations as technology changes. Independent geographic replicas, a fixed hardware-refresh programme, and independent archival custody remain future work. Henedo does not currently operate the previously described ten-year refresh cycle.
Included in the current cloud offer
- Encrypted archive objects stored in Cloudflare R2
- Dashboard upload and sealing after confirmed payment
- Sealed manifest and Merkle integrity verification
- Separate access keys for each inheritor
- Email delivery of inheritor access material
- Purchased capacity and preservation term recorded on your account
Primary storage
Encrypted cloud archive objects
Cloudflare R2
Current entry price
One-time purchase, separate from a Living membership
$699 once
Archive capacity
The capacity recorded on the purchase
100 GiB
Preservation term
Requires continuing preservation operations
100 years
Integrity checks
Merkle proofs verify archive content
Sealed manifest
Inheritor delivery
Access material for each named inheritor
Physical delivery
No disc or shipping in the current cloud offer
Legacy contracts only
Physical delivery under legacy contracts
Legacy purchases that include M-DISC delivery retain their contracted physical fulfilment and split-key access process. Those terms apply to the original purchase. New cloud archives use email access and include no physical disc, shipping, or offline recovery package.
Infrastructure Architecture
Designed to outlastany single provider.
Every request flows through edge functions that call abstract adapters, never the database directly. This means the entire infrastructure can be migrated without rewriting a single line of business logic or changing the client.
Database
Abstract adapter, Postgres
Current: Supabase Postgres. Future: self-hosted or AWS RDS
All queries go through a DatabaseAdapter interface. Swap implementation, not logic.
Storage
Abstract adapter, object storage
Current: Cloudflare R2 (Supabase Storage for local dev). Future: MinIO or AWS S3
Encrypted blobs uploaded via signed URLs. StorageAdapter abstracts the provider.
Auth & Email
Abstract adapters, auth + email
Current: Supabase Auth + Resend. Future: Lucia / custom JWT + SES
Auth verifies requests, email dispatches COTKs. Both are adapter-isolated.
Zero vendor lock-in
No direct client-to-database connections exist anywhere in the codebase. Every query goes through an abstract adapter. Swapping Supabase for self-hosted Postgres, S3, and custom JWT means swapping adapter implementations, not rewriting logic. Total estimated migration effort: 1 to 2 sprints.
Access Architecture
Access after death,without breaking encryption.
The hardest problem in digital legacy is granting access after death without creating a backdoor during life. We solve this with a Contact One-Time Key (COTK) and Trusted Delivery: the server is a blind gatekeeper that controls when, never what.
Contact One-Time Key (COTK)
When you designate a trusted contact, a 256-bit random key is generated entirely on your device. This COTK encrypts a bundle containing the contact's assigned file keys. The server stores the encrypted bundle but never the COTK itself.
Key delivery at designation
The access key is emailed to the contact the day you designate them, years before it is needed. The final COTK is derived via Argon2id (256 MB memory) from that input, so each brute-force guess costs around 2 seconds.
Trusted Delivery
You set an inactivity threshold (e.g., 180 days). If you stop checking in, escalating warnings are sent over several weeks. Only after the final warning expires are contact bundles activated. Any login resets the timer.
Server-gated access
The encrypted bundle is decryptable from day one. What changes at DMS trigger is the server's willingness to serve it. Contacts visit their access URL, enter their key (or card + email code), and decrypt entirely in-browser. We never see the key.
Trusted Delivery
You set an inactivity threshold. If you go silent, warnings escalate: first warning, second warning, final 7-day notice. Only after the final window expires are trusted contacts activated. Any login or check-in resets back to active.
Trusted contacts
Designate trusted people, each with their own COTK and encrypted bundle. Contacts do not need a Henedo account. You control which files each contact can access, and you can revoke or reassign at any time.
What this means in practice
No court order, warrant, or subpoena can compel Henedo to grant access to a vault. We mathematically cannot: the plaintext key does not exist on our infrastructure.
Long-Term Preservation
What happensif Henedo disappears.
The current cloud archive depends on continuing storage and access services. An independent preservation reserve and archival custodian remain planning work. Keep copies of your original files and recovery material; a preservation term alone does not remove service-continuity risk.
Preservation Endowment
The financial plan allocates part of each Eternal Vault sale toward preservation. An independently held reserve and trust structure remain planned; the current offer does not establish that those funds have already been ring-fenced or that investment returns are guaranteed.
Third-Party Custodian
Independent archival custody and a wind-down transfer arrangement remain planned. No contracted custodian is claimed here. Physical preservation applies only where an existing legacy purchase includes it; it is not part of the current cloud offer.
Open Data Format
The archive uses documented encryption and integrity formats. Recovery without Henedo requires the complete encrypted content, manifest, decryption tools, and the appropriate keys. Possessing an access email alone does not replace a complete archive copy.
Planned
Independent preservation reserve
Planned
Independent archival custody
Complete copy
Required for independent recovery
Academic & Research Partnerships
Independent oversight, from institutionsthat outlast companies.
Commercial incentives can conflict with security. Our answer is independent oversight from institutions whose reputations depend on rigour, not revenue. This is the oversight we are standing up: none of the engagements below is contracted yet, and we name each institution when we sign.
Cryptography Review
University Cryptography Departments
Planned: annual review of our encryption primitives, key derivation parameters, and protocol design, with any deviation from recommended standards triggering remediation within 90 days and the report published on our Transparency page. Not yet engaged, and the first formal third-party review is scheduled for Q3 2026. What is verifiable today is the published architecture spec and the signed build log.
Digital Archival Science
Library & Archival Science Programs
Planned: partnership with digital humanities departments to check our archival practices against ISO 14721 (OAIS) and PREMIS preservation metadata standards, followed by an annual archival health audit. Not yet engaged, and no department is contracted; we name the institution when we sign. What is verifiable today is that the archival design is published and the vault format is documented inside every vault.
Estate Law Research
Law School Estate Planning Clinics
Planned: collaboration with estate planning law clinics on template accuracy, jurisdiction-specific legal validity worldwide, and the evolving legal landscape around digital estate and cryptocurrency inheritance. No clinic is engaged yet; we name the school when we sign. Until then our templates carry the same caveat they always have, which is that we are not lawyers and complex estates need one.
Security Penetration Testing
Independent Security Research Teams
Planned: annual red-team engagement by a third-party security firm covering API endpoints, key management, client-side crypto, executor flows, and infrastructure, with the full report published including severity ratings. First engagement scheduled for Q3 2026; the firm is named when contracted. The bug bounty ($5,000 to $25,000) is live today.
Compliance & Certifications
The standardswe hold ourselves to.
SOC 2 Type II
In Progress, Q4 2026- Security, availability, confidentiality trust service criteria
- Continuous monitoring via Vanta
- Annual third-party audit by accredited CPA firm
- Report available to enterprise customers under NDA
GDPR (EU)
In Progress- Right to erasure: full vault deletion within 24 hours
- Data portability: full export at any time
- Data Processing Agreement available on request
- EU-only data residency is not yet in place; blobs sit on multi-region object storage
- No DPO appointed yet; a named data protection contact is published in the privacy policy
CCPA (California)
Compliant- Do Not Sell My Personal Information honoured
- Full data inventory available on request
- Opt-out of analytics and marketing data processing
- Data deletion processed within 45 days
Penetration Testing
First engagement: Q3 2026- Full-scope black-box and white-box tests
- OWASP Top 10 coverage + cryptography review
- All critical/high findings remediated within 30 days
- Summary report will be published on the Transparency page when the first engagement completes
Transparency & Open Verification
What we promise,and how to verify it.
Trust is not a marketing position. Each commitment below is backed by an artifact you can check today (the published crypto spec, signed build manifests, the public schema) plus the audits as they land, so a researcher can confirm the policy is wired to reality.
Commitments
Zero key-disclosure policy
We will publicly disclose any government or legal request to access user data. Because we hold only ciphertext, we can comply with the letter of any data access order while providing nothing useful to an adversary.
Breach notification within 72 hours
In the event of a confirmed breach, we will notify all potentially affected users within 72 hours and publish a detailed post-mortem within 30 days. There is no 'assess the situation first' delay.
Annual transparency report
We will publish each January, starting January 2027: total number of government data requests received, number we complied with, number we contested, all security incidents and their outcomes, and a summary of all third-party audit findings.
No behavioural analytics on vault content
We do not analyse, index, or run machine-learning models on your encrypted vault content. The only telemetry we collect is product usage analytics (page views, feature interaction) that never include document content or metadata.
Warrant canary
As of April 2, 2026: Henedo has not received any government request to compromise encryption, insert backdoors, weaken key derivation parameters, or provide decryption keys. Henedo has not received any National Security Letter or FISA court order. Henedo has not been subject to any gag order preventing disclosure of government data requests. This statement is updated quarterly. If it disappears or is not updated, draw your own conclusions.
Verifiable artifacts
Published cryptographic design
The full cryptographic design is published line by line in SECURITY.md. Every key derivation, encryption step, FEK wrap, COTK generation, and memory-zeroing routine is specified in the open, and the standalone offline decryptor at /henedo-decrypt.html is shippable proof the spec is sufficient to decrypt without us. Publishing the crypto module itself as an open-source package is on the roadmap.
Modules specified in SECURITY.md: aes.ts, argon2.ts, hkdf.ts, fek.ts, cotk.ts, evik.ts, session.ts, ask.ts, webauthn.ts, shamir.ts, escrow.ts, worker.ts, metadata.ts, encoding.ts
Signed build manifests with integrity verification
Every release publishes SHA-384 hashes of all JavaScript, CSS, and WASM assets in a manifest signed during the CI build, injected as SRI integrity attributes. The in-browser verifier fetches the manifest, checks the signature against the embedded public key, hashes each asset it loaded, and compares. If they differ, someone tampered with the build. Reproducible builds from public tagged source are on the roadmap.
Deterministic Vite builds · Pinned dependencies · npm ci · SRI (Subresource Integrity) attributes on all script tags
Third-party security audits (published in full)
When independent security firms review our cryptographic protocol, Web Crypto API usage, server-side ciphertext-only storage, and Master Key lifecycle, we publish the full report: not a summary, not a press release, the actual PDF. The first review is scheduled for Q3 2026 and the firm is named when contracted. Until then the architecture itself is the artifact: SECURITY.md is public and citable line by line.
Scope: protocol review · implementation audit · server-side verification · key management lifecycle · penetration testing
Server-side proof: database column audit
Our database schema is public. Every column that stores user data is documented: which ones hold ciphertext (EMK, EFEK, encrypted_bundle), which hold non-secret metadata (kdf_salt, IVs), and which hold plaintext (email, contact names needed for DMS operations). No hidden columns.
Tables: user_kdf_params · vault_files · journal_entries · trusted_contacts · eternal_vaults · eternal_vault_inheritors
Don't Trust. Verify.
Prove it yourself.Right now.
We don't ask you to take our word for it. Every claim on this page is independently verifiable using tools already in your browser. Here are four ways to confirm our zero-knowledge architecture is real.
1. Watch the network tab
Open DevTools → Network tab. Upload a file. Every outbound request carries application/octet-stream ciphertext bytes, never your file's real MIME type, never plaintext. The server receives encrypted blobs it cannot read.
// What leaves your browser: PUT /storage/v1/object/vault/... Content-Type: application/octet-stream Body: [AES-256-GCM ciphertext bytes] // What NEVER leaves your browser: // ✗ plaintext file content // ✗ real file MIME type // ✗ KEK, MK, or FEK key material
2. Read the cryptographic spec
Every function that touches your keys (derivation, wrapping, encryption, zeroing) is specified line by line, module by module, in our published SECURITY.md. Releasing the crypto layer itself as an open-source package is on the roadmap.
Your own vault's data path is symmetric end to end: sealed with AES-256-GCM under keys only you can derive. No RSA and no ECDSA stands between you and your data. That is by design.
3. Inspect the key boundary
The Master Key is generated and opened in a dedicated Web Worker. The page receives an operation handle, never the raw key. By default, encrypted browser state keeps the vault unlocked across refreshes until your chosen idle timeout. Its wrapping key is locally usable, so this is not a memory-only session. Malicious page code can still use that key, request cryptographic operations, or capture readable content.
// These legacy plaintext key slots must be absent:
['hrd_mk_v2', 'hrd_mk'].map(key => ({
key,
session: sessionStorage.getItem(key),
local: localStorage.getItem(key)
}))
// All values should be null, including while unlocked.
// With "Keep vault unlocked" enabled, reload before idle expiry:
// the vault resumes without resetting its idle deadline.
// Lock manually, then reload: a fresh unlock must be required.
// The encrypted resume envelope and its local wrapping key are separate.
// Inspect worker messages: key handles contain an ID, not key bytes.
// Storage checks alone do not prove the entire security model.4. The ultimate proof: password loss = data loss
This is the single strongest proof that our zero-knowledge claims are real. No company that secretly holds your keys would ever ship this behavior:
- If you lose your password and recovery key, your data is permanently gone
- No “contact support” backdoor exists. We cannot recover your Master Key
- No court order, subpoena, or government request can compel us to decrypt your data
- We literally do not have the mathematical ability to help because the KEK exists only in your browser
If we secretly held your keys, we could offer password recovery. We can't. That's the proof.
Standing challenge
Prove us wrong. We'll pay you.
We publish encrypted vaults with known plaintext inside, alongside every server-stored value: EMK, kdf_salt, mk_iv, EFEK, ciphertext, and IVs. Recover the plaintext without the password.
If the server could decrypt your data, someone would claim the bounty. No one has. No one can.
Post-Quantum Security
Quantum-safe by design.Not quantum-retrofitted.
Most encrypted products depend on RSA or elliptic-curve key exchange, algorithms that break completely under Shor's algorithm. Your own vault never uses any of them: every key from your passphrase down to each individual file is wrapped symmetrically, so there is nothing to retrofit. Where a key genuinely has to travel between two people — sharing with your partner — we wrap it with X25519and ML-KEM-768 together, so a future quantum computer would have to break both.
The mathematical bottom line
NIST Post-Quantum Security Level 1 requirement: 128-bit security
Henedo data encryption (AES-256-GCM): 128-bit PQ security ✓
Henedo key derivation (Argon2id): Hash-based, immune ✓
Henedo domain separation (HKDF-SHA-256): 128-bit PQ security ✓
Henedo partner sharing (X25519 + ML-KEM-768): NIST FIPS 203 ✓
Henedo vault signatures (ML-DSA-65): NIST FIPS 204 ✓
Henedo Eternal Vault third leg (SLH-DSA): NIST FIPS 205 ✓
Asymmetric algorithms vulnerable to Shor's:
RSA used by henedo: NOWHERE
ECDSA used by henedo: NOWHERE
ECDH used by henedo: ONLY inside the hybrid partner-sharing wrap,
alongside ML-KEM-768, never on its own
Verdict: your vault is quantum-safe today. Not planned. Shipped.Questions
Security FAQEverything you want to know.
Every file is encrypted client-side with AES-256-GCM using a random File Encryption Key (FEK). FEKs are wrapped with your Master Key (MK). The MK is encrypted with a KEK derived from Argon2id(passphrase + device-bound Account Secret Key, salt). These stored file bodies remain encrypted. Optional Life Book composition sends selected written answers through our backend to Anthropic after your consent; the resulting book is encrypted before storage.
Yes. Your data is protected by AES-256-GCM, which retains 128 bits of security under Grover's algorithm, and every key above it is wrapped symmetrically, so there is no Shor exposure to retrofit. Argon2id and HKDF are hash-based and immune to Shor. The one place a shared key travels between two people, partner sharing, uses a hybrid X25519 + ML-KEM-768 (NIST FIPS 203) wrap, so an attacker would have to break both. For authenticity, Eternal Vaults are signed with Ed25519 + ML-DSA-65 (NIST FIPS 204) and, on the current format, a third hash-based SLH-DSA signature (NIST FIPS 205). Verification requires every signature to check out.
Stored vault documents are encrypted with keys the service does not hold. A breach can still expose account, billing, and delivery information. Optional Life Book composition also processes selected written answers as plaintext during the consented request. Canary blobs planted in every vault also trigger an automatic Security Lockdown if an attacker bypasses RLS and enumerates files.
Henedo does not hold the keys to decrypt your stored vault documents. Account, billing, and delivery information are processed by the service. If you consent to optional Life Book composition, selected written answers pass through our backend to Anthropic as plaintext; the finished book is encrypted in your browser before storage.
Every production build of Henedo is signed with an Ed25519 key during the CI build, and the manifest is published to a public transparency log. The signing key is held in the build environment, not on an air-gapped machine, so this defends against a tampered CDN or a swapped bundle, not against someone who already controls our CI. The client verifies that the JavaScript it is running matches the signed manifest.
Ready to start?
Your legacy isworth protecting.
Start with a free will draft. Choose a Living membership for ongoing storage and sharing, or an Eternal Vault purchase for a sealed encrypted cloud archive. Stored vault content uses the encryption described on this page.