Built to be unreadableto everyone. Including us.

Core principles

Three layers of protection,at every level of the stack.

Security without compromise, at every level of the stack: from the cryptographic primitive to a physical archival medium rated for up to 1,000 years.

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.

// 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, plaintext

Data at Rest & In Transit

What we store,and what we never see.

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.

Active Preservation

Geo-redundant primary storage,not passive cold storage.

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.

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 a Dead Man's Switch: the server is a blind gatekeeper that controls when, never what.

Long-Term Preservation

What happensif Henedo disappears.

Every subscription-based company is at risk of shutdown, acquisition, or pivot. We have taken structural steps to ensure your legacy survives regardless of our commercial fate.

Academic & Research Partnerships

Independent oversight, from institutionsthat outlast companies.

Commercial incentives can conflict with security. We counter this by embedding independent academic oversight into our architecture: institutions whose reputations depend on rigour, not revenue.

Compliance & Certifications

The standardswe hold ourselves to.

Transparency

Whatwe will always tell you.

Trust is not a marketing position. It is a set of commitments with teeth. These are the transparency obligations we hold ourselves to, regardless of commercial or legal pressure.

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.

// 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

// In DevTools Console, verify what's in sessionStorage:
const emk = sessionStorage.getItem('henedo_emk')
console.log('EMK length (base64):', emk?.length)
// ~64 chars base64 = 48 bytes = 32 (MK) + 16 (GCM tag) ✓

// The MK itself lives in the Web Worker scope.
// Main thread cannot access Worker variables.
// Try it: there is no global 'masterKey' variable.
typeof masterKey  // → "undefined" ✓

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. Henedo's data protection uses no asymmetric cryptography at all. There is nothing to retrofit because there is nothing to break.

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 vault signatures (ML-DSA-65):               NIST FIPS 204        ✓

Asymmetric algorithms vulnerable to Shor's:
  RSA         used by henedo: NOWHERE
  ECDH        used by henedo: NOWHERE
  ECDSA       used by henedo: NOWHERE
  X25519      used by henedo: NOWHERE

Verdict: Henedo's data protection is quantum-safe today. Not planned. Shipped.

Open Verification

Open source.Reproducible. Audited.

Trust claims without verification are marketing. We publish our cryptographic code, our build process, and our audit reports so anyone can confirm that what runs in your browser matches what we describe.

Questions

Security FAQEverything you want to know.