Skip to content

Security

How we keep your vault safe

Your secrets are encrypted at rest the moment they reach our servers, and only decrypted when your vault executes. Guardian's Recovery Vault goes further: it encrypts entirely in your browser before anything ever leaves your device. Here's exactly how we do it.

The short version, in plain English

Encryption at rest

Every note is encrypted with Fernet symmetric encryption, and every file is encrypted with streaming AES-256-GCM, before it's written to storage. The encryption key is stored separately from your content, so even if someone copied the database, they'd have meaningless bytes.

  • ✓ Industry-standard symmetric encryption (Fernet for notes, AES-256-GCM for files)
  • ✓ Unique encrypted blob per item
  • ✓ Plaintext never stored, not even temporarily

We never see your content

Your notes and files are encrypted before storage. Our servers, logs, and staff never have access to the plaintext of what you've written. Titles are stored unencrypted (to help you stay organised), but content is always encrypted.

  • ✓ No plaintext in application logs
  • ✓ No plaintext in database backups
  • ✓ Staff cannot read your notes

Two-Person Secret (split delivery)

For extra-sensitive items, you can opt for our Two-Person Secret mode. When your vault executes, the secret is mathematically split into a separate share for each of your selected recipients (2 or more), using a well-established secret-sharing technique. Any 2 of those shares are enough to reconstruct the original message, but a single share, on its own, reveals absolutely nothing about it.

  • ✓ Cryptographically impossible to read with only one share
  • ✓ Any 2 of N shares reconstruct the secret. Even if you lose touch with one trusted contact, any 2 of the others can still unlock it
  • ✓ Shares never stored together after generation

Text notes

The note text itself is split among your recipients. Any 2 of them paste their shares into notenz.com/reconstruct/, and the original message is rebuilt entirely in their browser. Nothing is sent back to Notenz.

  • ✓ Reconstruction is 100% client-side, with no server round-trip
  • ✓ Notenz never holds the reconstructed plaintext

Files

For files, Notenz splits the access to the file, not the file itself. A short random access token is split among your recipients using the same scheme. When any 2 of them combine their shares at the reconstruct page, the browser uses the reassembled token to request the file. Notenz decrypts it server-side and streams it as a direct download. No single share alone can produce the token.

  • ✓ Only the access token is split. No binary file is sent via email
  • ✓ File stored AES-256-GCM encrypted at rest; decrypted only at the moment of download
  • ✓ Download link valid for 90 days; expires automatically after that

Recovery Vault: Zero-Knowledge Encryption

Guardian

Recovery Vault items are encrypted entirely in your browser before upload. Notenz's servers store only ciphertext: never your plaintext secrets, never your encryption key. Even a full Notenz database breach exposes nothing readable.

Technical specification

  • Key derivation: PBKDF2-SHA256, 600,000 iterations
  • Encryption: AES-GCM 256-bit
  • IV: Random 12 bytes per secret, never reused
  • Auth tag: AES-GCM authentication tag detects tampering and wrong passwords
  • Runtime: All crypto runs in your browser via the Web Crypto API, so keys never leave your device

Important limitation

Recovery Vault requires your Notenz password to decrypt. If you forget your Notenz password, your vault secrets cannot be recovered. That's by design: there is no server-side backdoor.

Transport and infrastructure

All traffic between your browser and our servers is encrypted in transit using TLS (HTTPS). We use CSRF protection on all state-changing endpoints. Session cookies are marked as HttpOnly and Secure.

  • ✓ TLS/HTTPS only, HTTP is redirected
  • ✓ CSRF tokens on all POST/DELETE endpoints
  • ✓ HttpOnly + Secure session cookies
  • ✓ Hosted on secure cloud infrastructure

Login and authentication

Passwords are hashed using Django's PBKDF2 with SHA-256, the industry standard. We also support login via a one-time code sent to your email (no password required).

  • ✓ PBKDF2-SHA256 password hashing
  • ✓ Email-code login option (one-time code)
  • ✓ OTP codes expire after 10 minutes

Found a security issue?

We take security reports seriously. If you've found a vulnerability, please email us at [email protected]. We'll respond within 48 hours and work with you to address the issue. We don't have a formal bug bounty programme yet, but we deeply appreciate responsible disclosure.