Skip to main content

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.

XChaCha20-Poly1305
XChaCha20-Poly1305
scrypt (N=2^15)
HKDF-SHA-256
Shamir Secret Sharing
TLS 1.2 / 1.3

Six-Layer Protection

Every Layer Has a Purpose

From your master password to our servers — each layer adds defense in depth.

1

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

2

Key Derivation

Master key derives category keys via HKDF-SHA-256 with domain separation

HKDF-SHA-256 with context labels: 'vault', 'credentials', 'documents', etc.

3

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

4

Envelope Encryption

DEKs wrapped with category keys; only ciphertext leaves device

NIST SP 800-38F key wrapping; authenticated encryption (AEAD)

5

Threshold Secret Sharing

Vault master key split into N shares; K required for reconstruction

Shamir's Secret Sharing over GF(2^8)

6

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.

XChaCha20-Poly1305
Every vault item and every document byte — there is no second content cipher

Strength

256-bit key, 192-bit nonce (random nonces, no reuse risk), 128-bit Poly1305 tag

Standard

RFC 8439 (XChaCha20 extended-nonce construction)

scrypt
Stretches your vault passphrase into your 256-bit master key, on your device

Strength

Memory-hard; N=2^15, r=8, p=1; per-user salt; NFKC-normalised input

Standard

RFC 7914

Argon2id
Hashes your ACCOUNT LOGIN password, server-side. A different password; it derives no keys

Strength

Memory-hard password hashing; never applied to the vault passphrase

Standard

RFC 9106 / Password Hashing Competition winner

HKDF-SHA-256
Key hierarchy derivation (master → category → asset keys)

Strength

SHA-256 PRF; domain separation via info parameter

Standard

RFC 5869

TLS 1.2 / 1.3
All network traffic (API, WebSocket, asset upload/download)

Strength

TLS 1.2 floor, 1.3 preferred; perfect forward secrecy

Standard

RFC 8446 / RFC 5246

Shamir Secret Sharing
Threshold vault key sharing (e.g., 3-of-5)

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

Critical

Server only holds ciphertext + wrapped DEKs. No master key, no category keys, no plaintext ever touches server.

Database Leak

Critical

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

High

TLS 1.2 floor with 1.3 preferred, certificate pinning on mobile, and HSTS with includeSubDomains on every response.

Device Theft

High

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

Medium

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

Medium

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 policy

Ready to Secure Your Digital Legacy?

Create your zero-knowledge vault in minutes. Your keys, your rules, your legacy.