Skip to content

Security

Security architecture and threat model

Notenz uses two fundamentally different encryption tiers. Normal vault items are encrypted server-side so we can deliver them automatically. Guardian's Sealed Vault and Shared-Key items are encrypted entirely in your browser: we never hold the key. This page explains exactly what each tier does, what we can and cannot read, and where the honest limits are.

The short version, in plain English

  • 🔐 Your notes are scrambled (encrypted) the moment they reach us. We store scrambled data, not readable text. Our staff don't read it.
  • 🔑 Your recipients can read it only when your vault executes. Not before.
  • 🤔 Could Notenz technically unlock it? For the default vault, yes: we hold the key needed to deliver it automatically if you can't. Read why, and how Sealed Vault is different →
  • 🌐 Your connection is always secure. Like online banking, the padlock in your browser is always on.
  • 🪪 Your password is never stored as-is. We store a one-way mathematical fingerprint of it. Even if our database was stolen, your password stays safe.
  • 🚨 Found a problem? Email [email protected] and we'll fix it fast.

Two-tier encryption model

Tier 1: Normal vault items

All Free, Pro, and Guardian items that are not Sealed Vault or Shared-Key. This covers the majority of vault content.

  • Text notes: Fernet (AES-128-CBC + HMAC-SHA256), server-side
  • Files: AES-256-GCM, chunked streaming, server-side
  • Key held by: Notenz (needed for automatic delivery)
Notenz can technically decrypt these items. We need that capability to deliver them automatically when you stop checking in.

Tier 2: Zero-knowledge (Guardian only)

Sealed Vault (Private Secrets) and Shared-Key Vault Items. Encrypted entirely in your browser before upload.

  • Sealed Vault: PBKDF2-SHA256, 600,000 iterations, AES-256-GCM
  • Shared-Key / Per-Item Phrase: PBKDF2-SHA256, 100,000 iterations, AES-256-GCM
  • Key held by: You only. Notenz stores ciphertext only.
Notenz cannot read these items. Not even a full server breach exposes their plaintext. Trade-off: forgotten key means permanent loss.

What Notenz can and cannot see

Notenz can read

  • Item titles (stored unencrypted to help you organise)
  • Normal vault item content (server-side key; needed for delivery)
  • Normal vault files (decrypted at time of delivery)
  • Your email address, check-in schedule, and recipient list
  • Metadata: when items were created, accessed, delivered

Notenz cannot read

  • Sealed Vault secrets (client-side key, never transmitted)
  • Shared-Key Vault Item content (client-side key, never transmitted)
  • Per-Item passphrase-encrypted content (client-side key)
  • Your account password (stored as PBKDF2-SHA256 hash only)
  • Two-factor codes (stored as HMAC-SHA256 digest only)

Threat model: what we protect against, and what we do not

We protect against

  • ✓ Database theft alone: all content is encrypted at rest; stolen database rows are meaningless without the master key
  • ✓ Server breach for Tier 2 items: Sealed Vault and Shared-Key ciphertext cannot be decrypted even with full server access, because the key never reaches our servers
  • ✓ Accidental staff access: no internal tooling exists to browse vault content
  • ✓ Brute-force on account passwords: PBKDF2-SHA256 stretching, rate-limited login
  • ✓ Token guessing: all public links are rate-limited and cryptographically random
  • ✓ Session fixation and CSRF: CSRF tokens on all state-changing endpoints, secure HttpOnly cookies

We do NOT protect against (honest limitations)

  • ✗ Full live-server compromise (Tier 1): an attacker with access to both the database and the master key can decrypt Normal vault items. We mitigate this with key rotation capability, but it remains a theoretical risk.
  • ✗ Normal vault items are not end-to-end encrypted to recipients: they are decrypted by our server and sent via email. TLS protects the email in transit, but we see the plaintext at delivery time.
  • ✗ Device compromise: if your device is compromised, a Tier 2 passphrase entered in your browser can be captured before encryption. No server-side measure can prevent this.
  • ✗ Forgotten Tier 2 passphrase: Sealed Vault and Shared-Key items become permanently unrecoverable. There is no server-side reset path.
  • ✗ Metadata: even for Tier 2 items, we store labels (titles), timestamps, and delivery addresses. Tier 2 hides content, not the existence of an item.
  • ✗ Notenz is not ISO 27001 certified. We are hosted on DigitalOcean, which holds ISO/IEC 27001:2013 certification as a cloud infrastructure provider.

Encryption at rest

Text notes are encrypted server-side with Fernet (AES-128-CBC + HMAC-SHA256) before being written to storage. Files use streaming AES-256-GCM (4 MB chunks, unique nonce per chunk). The master key is stored separately from content; a stolen database alone yields only ciphertext.

  • ✓ Text notes: Fernet (AES-128-CBC + HMAC-SHA256), server-side key
  • ✓ Files: AES-256-GCM streaming (unique 12-byte nonce per chunk), server-side key
  • ✓ Master key stored separately from database; key rotation tooling available
  • ✓ Plaintext never written to disk or logs

We don't read your content

Your notes and files are encrypted before storage. In normal day-to-day operation, nobody at Notenz looks at, browses, or has a tool to read the plaintext of what you've written. Titles are stored unencrypted (to help you stay organised), but content is always encrypted. Automated processes only decrypt content to deliver your vault when it's time: see below for the full picture.

  • ✓ No plaintext in application logs
  • ✓ No plaintext in database backups
  • ✓ No staff tooling to browse vault content

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

Honest limitation, for transparency

Unlike Shared-Key items, Notenz does hold your Two-Person Secret content: we store the split shares ourselves until your vault executes, so we can combine and deliver them. That means it is not zero-knowledge, and a personal data export (Settings → Export My Data) includes this content in readable form. If you need a guarantee that even Notenz cannot read the content, use a Shared-Key Vault Item instead.

Protection for shared links

Delivery links, split-secret share links, recipient confirmation links, and recall links are all protected against automated guessing and abuse. If a single link receives an unusually high number of requests from the same source, further requests are temporarily blocked and the vault owner is notified by email so they can review their account's audit log.

  • ✓ Rate limiting on all token-based public links (delivery, split-secret, confirmation, and recall pages)
  • ✓ Vault owner gets a one-time email alert the first time a delivery or split-secret link is accessed
  • ✓ Suspicious activity is recorded in your account's audit log

Honest answer: could Notenz read my vault?

For your default vault (Free, Pro, and Guardian items outside Sealed Vault): technically, yes. Here's why, in plain terms.

Notenz's whole job is to deliver your vault automatically if you stop checking in, even if you're no longer able to type a password yourself. For that to work, our system has to be able to unlock your vault on its own, without you. So we keep a master key that can do that.

That means: if someone broke into a stolen database backup alone, they'd find nothing but scrambled bytes: useless without the key. But if someone fully broke into our live servers (not just the database), they could, in theory, get the key too and unlock your vault. We guard hard against that (separate storage for the key, no staff access, encrypted backups, and we're rolling out key-rotation tooling so a leaked key can be replaced quickly), but it's an honest limit, not a guarantee of "nobody, ever, under any circumstances."

Want a vault even Notenz can never open, period? Use Sealed Vault (Guardian). It's encrypted in your browser using your password. We never have the key, full stop. The trade-off: it can't be delivered automatically, and if you forget your password, it's gone for good.

Want that same "Notenz can never open it" guarantee, but the item still needs to be delivered to a recipient? Use a Shared-Key Vault Item (Guardian). You generate your own key in your browser, Notenz never sees it, and the item is still delivered to your recipient as normal, but only you can give them the key to open it.

Sealed Vault: Zero-Knowledge Encryption

Guardian

Sealed 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

Sealed 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.

Want Sealed Vault to survive an account password reset?

By default, Sealed Vault uses your normal Notenz login password. If you ever reset that password (e.g. via "forgot password"), your existing Sealed Vault secrets become unreadable, because they were encrypted with the old password.

To avoid this, you can turn on a separate Sealed Vault password from the Sealed Vault page: a second password used only to unlock your most sensitive secrets, completely independent of your account login. Resetting your account password will no longer affect it.

The same rule applies, only more so: if you forget this separate password, Notenz cannot recover your Sealed Vault secrets, full stop. There is no reset link, no support override, and no way for us to help. Write it down somewhere safe before you turn this on.

Letting someone else access it later

Sealed Vault is never auto-delivered on vault execution. To let a trusted person in eventually, give them two separate things yourself, outside Notenz: access to your Notenz account login, and your Sealed Vault password.

Keep these two apart (e.g. account details with an executor, the Sealed Vault password in a sealed letter or with a lawyer): whoever has both can unlock it; whoever has only one cannot.

Shared-Key Vault Item: end-to-end encryption that still gets delivered

Guardian

Sealed Vault gives you a "Notenz can never read this" guarantee, but it can't be delivered to anyone. It's just for you. A Shared-Key Vault Item gives you that same guarantee for an item you do want delivered to a recipient.

When you add this kind of item, your browser generates a random secret key and uses it to scramble your note or file before it's ever sent to Notenz. We store only the scrambled version. We never see, store, or have any way to reconstruct your key. When your vault executes, your recipient receives this item like any other, plus a simple unlock page built into the delivery link. To open it, they paste in the key.

  • ✓ Scrambled in your browser before it ever reaches Notenz: we only ever store the locked version
  • ✓ Still delivered to your recipient automatically when your vault executes, just like other items
  • ✓ Recipient gets a built-in unlock page on the delivery link where they enter the key to read or download it

You must hand over the key yourself: please read this carefully

Notenz never has this key. That's the whole point, but it also means getting the key to your recipient is entirely your job, not ours. Send it to them however you'd share something sensitive: in person, over a phone call, through an end-to-end-encrypted chat app like Signal, anywhere except by leaving it sitting next to the item itself.

If you lose the key, or never get around to sharing it, your recipient will still receive the item when your vault executes, but they will never be able to open it. The data inside is permanently locked. Notenz cannot recover it, reset it, or generate a replacement key. There is no support process that can fix this.

Use this for the handful of things that need both maximum secrecy and delivery. For everything else, the default vault (which we can deliver automatically even if you lose access to everything) is the safer everyday choice.

Per-Item Phrase Encryption

Guardian

Guardian users can protect any vault item with a memorable 4-word passphrase generated in the browser (technically: Web Crypto PBKDF2, 100,000 iterations, SHA-256, AES-256-GCM). The phrase is never transmitted to Notenz servers. Recipients enter it at the delivery link to decrypt content client-side. This works independently of or in combination with Two-Person Secret (Shamir sharing: splits the key so 2 trusted people have to unlock it together).

If Notenz ever disappears

Zero-knowledge encryption means Notenz never holds your keys, which also means Notenz is not required to decrypt your content: only the passphrase and the standard cryptography are. We publish a standalone offline decryption tool that runs entirely in a saved browser page, with no server, no login, and no external requests. Save a copy now: it will keep working with your passphrase even if Notenz's servers are unreachable.

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 redirects to HTTPS
  • ✓ CSRF tokens on all POST/DELETE endpoints
  • ✓ HttpOnly + Secure session cookies
  • ✓ Hosted on DigitalOcean, an ISO/IEC 27001:2013-certified cloud infrastructure provider. Notenz itself is not ISO 27001 certified.
  • ✓ EU-region data centre

Login and authentication

Passwords are hashed with PBKDF2-SHA256 (Django default). Two-factor authentication (2FA) via email one-time code is enabled by default for all accounts. Guardian accounts cannot disable it.

  • ✓ PBKDF2-SHA256 password hashing (Django default, industry standard)
  • ✓ Email 2FA enabled by default for all plan tiers
  • ✓ Guardian plan: 2FA is mandatory and cannot be disabled
  • ✓ 2FA codes stored as HMAC-SHA256 digest, not the raw code
  • ✓ OTP codes expire after 5 minutes
  • ✓ 2FA verification required (in the current session) before 2FA can be disabled
  • ✓ Rate-limited: max 5 verification attempts per 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.