Security

Security built for a zero-knowledge vault

Lastkey encrypts vault content on your device before upload. Our servers store ciphertext only, and vault keys are split so no single system can decrypt your data by itself.

Zero-knowledge by design

Vault items are encrypted locally. Lastkey stores ciphertext only and cannot read your notes or files.

Secret sharing keys

The vault master key is split using 2-of-3 Shamir secret sharing so no single share can unlock a vault.

Local unlock options

Unlock uses your Vault PIN or an optional passkey. Passkeys rely on WebAuthn user verification and never share biometrics with Lastkey.

Minimal PII

We collect the minimum required for vault operations. Beneficiary emails are used for invites and replaced with account IDs when possible.

Cryptography we use
  • AES-256-GCM for vault item encryption.
  • HKDF-SHA256 to derive per-item data keys.
  • PBKDF2-HMAC-SHA256 for PIN-based wrapping (phase 1).
  • WebAuthn PRF + HKDF for passkey-based unlock (optional).
  • Planned upgrade to Argon2id when available across platforms.
What never happens
  • No plaintext vault content ever reaches the backend.
  • No plaintext key shares are stored on our servers.
  • No secrets are logged or captured in analytics.
  • No auto-claim of invites on page load.

How vault encryption works

Encryption and key handling are designed to keep secrets on user devices and to reduce single points of compromise.

On-device encryption
  1. 1. Your device generates a vault master key (VMK).
  2. 2. Each item gets a unique data key derived from the VMK.
  3. 3. Items are encrypted locally before upload.
  4. 4. Lastkey stores only ciphertext and minimal metadata.
Share distribution
  1. 1. The VMK is split into three shares (2-of-3 required).
  2. 2. Share A stays on the owner device (never uploaded).
  3. 3. Share B is stored server-side as ciphertext only.
  4. 4. Share C is delivered to beneficiaries via a secure invite flow.

Invite and release safety

Invite links use a URL fragment key that never reaches our servers. Releases require explicit user action and authenticated access.

Fragment keys

The decryption key lives after the # in the URL, so it is never sent to Lastkey or logged by the server.

One-time invites

Invites are designed to be one-time, expiring, and revocable to limit exposure if an email is compromised.

Explicit claim flow

Claiming requires deliberate user action to protect against automated email scanners.

Threat model and limits

Security is about tradeoffs. These are the primary protections we provide and the scenarios where you still need to stay vigilant.

What we protect against
  • Server breaches that expose stored data.
  • Email link interception without the fragment key.
  • Invite enumeration via rate limits and high-entropy IDs.
  • Backend access by insiders without owner keys.
Where you still matter
  • If a device is compromised, local secrets can be exposed.
  • Sharing your Vault PIN undermines encryption safeguards.
  • Phishing can still trick users into approving access.
  • Backups and screenshots can leak sensitive content.

Operational safeguards

We combine crypto with practical product safeguards to limit accidental exposure.

No secret logging

URL fragments, key shares, and decrypted content are never logged or sent to analytics.

Auto-lock and manual lock

Vault sessions auto-lock after inactivity, with manual lock controls for shared devices.

Clear fragment handling

After decrypting invites, the URL fragment is cleared to prevent key leakage through history.

Incident response baseline

If we suspect a security issue, we disable affected endpoints, preserve evidence without collecting secrets, patch the issue with regression tests, and notify stakeholders when required.