Zero-Knowledge Architecture & Risk Disclosure

1. Purpose

This document describes the zero-knowledge architecture of EternaKeys and discloses the inherent risks of a system designed so that the service provider cannot access user content.

2. How Zero-Knowledge Works at EternaKeys

EternaKeys uses a zero-knowledge architecture: vault content is encrypted on your device before transmission. The server stores only ciphertext and operational metadata necessary for the service to function.

2.1 Encryption

• Vault content is encrypted with AES-256-GCM using per-item random nonces.
• Encryption keys are derived from your vault passphrase using Argon2id key derivation.
• Your vault passphrase never leaves your device — not during setup, not during use, not ever.

2.2 What the Server Stores

• Ciphertext: Encrypted vault item content that cannot be decrypted without your passphrase.
• Operational metadata: Item types, sizes, timestamps, account information, designated recipient settings, audit logs, and session data. This metadata is necessary for the service to function but does not include plaintext vault content.
• KDF parameters: Salt and configuration needed to re-derive your encryption keys from your passphrase on your device.

3. Risk Disclosure

3.1 Credential Loss — Account Access

Standard user accounts authenticate exclusively via passkeys (hardware keys or platform authenticators). If all registered passkeys are lost and no backup passkey is available, account access cannot be restored. EternaKeys does not store passwords for standard user accounts and cannot reset passkey credentials on your behalf.

3.2 Credential Loss — Vault Data

Your vault passphrase is the sole key to your encrypted data. Because we never receive your vault passphrase, we have no mechanism to reset it, recover it, or decrypt your data on your behalf. If your vault passphrase is lost, encrypted vault data is permanently and irreversibly inaccessible. This is a fundamental property of the zero-knowledge architecture, not an operational limitation.

3.3 Device Compromise

If your device is compromised by malware, an attacker could potentially intercept your vault passphrase or decrypted content. EternaKeys requires WebAuthn/passkey authentication for every sign-in: alongside possession of your registered authenticator, user verification (a biometric or device PIN) is required, so two factors are checked in a single step, and the credential itself cannot be phished or replayed. Standard accounts do not use a separate authenticator-app code; that path exists only for administrative accounts. None of these controls can fully protect against a compromised device — an attacker who controls your unlocked device can act after you have already authenticated.

3.4 Metadata Visibility

While vault content is encrypted, operational metadata (item types, sizes, timestamps, and account information) is visible to the service. This metadata is necessary for functionality but could reveal information about your usage patterns.

Search markers. To let you search without our servers reading your items, your device derives keyed markers (HMAC-SHA256 under a search key that is separate from your content key) from the words in the non-secret fields of your items, including free-text fields such as the text of a medical or legal directive, and we store them next to the encrypted item. The service cannot read the words. It can see, for each item, how many markers it has (at most 50), which of your items share a marker (that is, share a word), and which items match each search you run. The search key is derived from your passphrase on your device and is never sent to us.

3.5 No Absolute Guarantee

No security system can guarantee absolute protection. EternaKeys is designed to minimize risk through client-side encryption, but device compromise, credential loss, or implementation limitations remain relevant factors.

3.6 Code Delivery

Your vault passphrase is typed into a page whose code EternaKeys serves to your browser. The vault is encrypted on your device, but the code that does it comes from us, so a compromised or malicious deployment could serve code that captures your passphrase. Content-security controls limit injection by third parties; they cannot constrain the operator or its deployment pipeline, and a way for you to check the code you are served is not yet available.

3.7 Authorized Access Package Authorship

A release package is sealed to the designated recipient's published access key and opened with that recipient's access passphrase. It has no owner signature, so the package alone does not prove who authored its contents. An operator with database write access could substitute a package. The recipient's published key is likewise fetched from our server when the owner confirms it (trust on fetch); the owner's one-tap confirmation guards against binding the wrong person, not against a compromised server substituting a key. Recipients should verify consequential instructions independently.

4. Your Responsibilities

• Store your vault passphrase securely (e.g., in a physical safe or with a trusted person).
• Register at least two passkeys (e.g., a hardware key and a platform authenticator) to protect against loss of a single credential.
• Keep your devices secure and up to date.
• If you configure designated recipient access, make sure any offline instructions you choose to provide are handled securely and never shared with EternaKeys.

5. Acknowledgment

By creating a vault, you acknowledge that you have read and understood these risks. You accept that credential loss may result in permanent, irreversible loss of access to your encrypted data.