Security Center → Encryption
Zero-Knowledge Encryption Architecture
Six layers of cryptographic protection. Your data is encrypted on your device before it ever leaves. We store only ciphertext.
The Minimum-Information Principle
Zero-Knowledge Vault ≠ Zero-Knowledge Verification
Your vault stays sealed. Verification only ever sees the one fact it needs — that a permitted event happened.
LifeWyn keeps the contents of your vault encrypted and out of our reach. Your documents, private messages, media and other protected content are encrypted before they leave your device, and we do not hold the keys to browse them.
A legacy service, though, has to do more than hold a sealed box. Life Signal, death-event verification, nominee notification, claim workflows and your legacy instructions all depend on establishing whether something has actually happened — and a system blind to every fact cannot verify anything. So we work to a minimum-information principle: at each step, LifeWyn processes only what that step requires, and nothing more.
Verification
establishes whether a permitted event has occurred.
Your rules
decide what may happen next.
Your encryption
protects the actual contents of your vault.
Vault access
The encrypted contents of your vault — documents, private messages, media and credentials.
Needs your keys, which never leave your device. No LifeWyn team member and no server-side process can open it.
Case access
A single verification case — for example, a death certificate a nominee submits.
A reviewer authorised for that case sees only what the case needs. That authorisation never reaches into your vault.
Verification access
Whether a permitted event has actually occurred — a missed Life Signal, a validated certificate.
Answers “did this happen?”, never “what is inside the vault?”.
A death certificate submitted by a nominee, for instance, can be reviewed to confirm a reported death. That review never unlocks the customer’s vault, passwords or unrelated assets — they stay encrypted throughout. Every step, from verification and review to notification, nominee access and disclosure, is bounded by your configured rules and the least information needed to complete it.
Six-Layer Protection
Every Layer Has a Purpose
From your master password to our servers — each layer adds defense in depth.
Vault passphrase & biometric
You enter your vault passphrase (separate from your account login password) with an optional biometric unlock
scrypt (N=2^15), memory-hard → 256-bit master key
Key Derivation
Master key derives category keys via HKDF-SHA-256 with domain separation
HKDF-SHA-256 with context labels: 'vault', 'credentials', 'documents', etc.
Item & document encryption
Asset keys are derived from the category key; each document gets a fresh random key wrapped under that category key
XChaCha20-Poly1305 (AEAD) — one cipher for vault items and file bytes alike
Envelope Encryption
DEKs wrapped with category keys; only ciphertext leaves device
NIST SP 800-38F key wrapping; authenticated encryption (AEAD)
Threshold Secret Sharing
Vault master key split into N shares; K required for reconstruction
Shamir's Secret Sharing over GF(2^8)
Server Storage
Only ciphertext + encrypted key envelopes stored; zero plaintext
PostgreSQL (ciphertext blobs); Redis (session); object storage (files)
Algorithm Specifications
Cryptographic Primitives — No Custom Crypto
We use only standardized, battle-tested algorithms. No proprietary constructions.
Strength
256-bit key, 192-bit nonce (random nonces, no reuse risk), 128-bit Poly1305 tag
Standard
RFC 8439 (XChaCha20 extended-nonce construction)
Strength
Memory-hard; N=2^15, r=8, p=1; per-user salt; NFKC-normalised input
Standard
RFC 7914
Strength
Memory-hard password hashing; never applied to the vault passphrase
Standard
RFC 9106 / Password Hashing Competition winner
Strength
SHA-256 PRF; domain separation via info parameter
Standard
RFC 5869
Strength
TLS 1.2 floor, 1.3 preferred; perfect forward secrecy
Standard
RFC 8446 / RFC 5246
Strength
GF(2^8) field; plain Shamir — shares carry no verifiability commitments
Standard
Adi Shamir 1979; RFC 9570 (draft)
Threat Model
What We Protect Against — And How
Honest assessment of attack vectors and our mitigations.
Server Compromise
Server only holds ciphertext + wrapped DEKs. No master key, no category keys, no plaintext ever touches server.
Database Leak
Stored vault data is XChaCha20-Poly1305 ciphertext. Without your master key — which never leaves your device — it is computationally infeasible to decrypt. Contact details for you and your nominees are NOT encrypted at rest: LifeWyn cannot notify or verify a nominee whose address it cannot read.
Man-in-the-Middle
TLS 1.2 floor with 1.3 preferred, certificate pinning on mobile, and HSTS with includeSubDomains on every response.
Device Theft
The master key is only ever re-derived from your passphrase with scrypt. Biometric unlock is bound to the iOS Keychain / Android Keystore, with auto-lock on inactivity and a wrapped-key wipe on biometric refusal.
Malicious Insider
There is no server-side decryption capability to abuse: all key operations are client-side, and every release gate is cross-checked from a separate deployable and fails closed. Every action is audited.
Supply Chain
Lockfile-pinned dependencies, an SBOM and a licence check generated on every pipeline run, and a secret scanner that hard-fails the build. Cryptography comes from audited published libraries, not from us.
Key Hierarchy
From Master Password to Asset Keys
Visual flow showing how your master password derives every encryption key in the system.
Master Key (256-bit)
scrypt(passphrase, salt, N=2^15) → 256-bit key
Vault Key
HKDF(master, 'vault')
Credentials Key
HKDF(master, 'credentials')
Documents Key
HKDF(master, 'documents')
Assets Key
HKDF(master, 'assets')
Bank Account
Document key = random 256-bit
Wrapped by Category Key
Insurance Policy
Document key = random 256-bit
Wrapped by Category Key
Will Document
Document key = random 256-bit
Wrapped by Category Key
Crypto Wallet
Document key = random 256-bit
Wrapped by Category Key
Property Deed
Document key = random 256-bit
Wrapped by Category Key
Investment
Document key = random 256-bit
Wrapped by Category Key
Medical Record
Document key = random 256-bit
Wrapped by Category Key
Digital Account
Document key = random 256-bit
Wrapped by Category Key
Verification
Don't Trust — Verify
What you can check yourself today — and what we have not done yet.
Audited primitives, not our own
Every primitive above is a published standard implemented by @noble/ciphers and @noble/hashes. We wrote no cryptography of our own. The application source is not public.
No third-party audit yet
No external firm has audited LifeWyn, and no penetration test has been commissioned. We would rather say so than imply otherwise. When one happens, the report will be linked here.
Coordinated disclosure
A published policy, a safe-harbour commitment and a real response clock. There is no cash bounty programme today.
Read the policyFAQ
Frequently asked questions
Last verified: September 2026 · Written by the LifeWyn editorial team · About LifeWyn
Ready to Secure Your Digital Legacy?
Create your zero-knowledge vault in minutes. Your keys, your rules, your legacy.