Privacy Policy
How we handle your data and why we can't read your secrets.
Last updated: September 25, 2026
Introduction
This policy explains what data we collect and how we handle it when you use our platform.
Zero‑Knowledge Architecture
We Cannot See Your Secrets
NoTrust.now implements a true zero‑knowledge architecture. All encryption and decryption happens client-side in your browser. We never have access to your unencrypted secrets.
CRITICAL: Mathematical Guarantee, Not a Policy
It is architecturally and mathematically IMPOSSIBLE for our servers to decrypt your secrets — even if we wanted to.
How this works: Each secret is sealed in your browser to the recipient's ML‑KEM‑768 public key. The encryption key combines the ML‑KEM shared secret, which only the recipient's private key can recover, with a key derived from your passphrase through scrypt, and the content is encrypted with ChaCha20‑Poly1305. The server never receives your passphrase or any private key and therefore cannot derive the decryption key. Without that key, decryption is computationally infeasible.
Your key vault: your ML‑KEM‑768 and ML‑DSA‑65 key pairs are generated in your browser and stored only there, in a vault encrypted with AES‑256‑GCM under a key derived from your vault password (PBKDF2‑HMAC‑SHA256, 600,000 iterations). Private keys and the vault password are never sent to us, so we cannot recover a lost vault or the secrets sealed to its keys.
- Secrets are encrypted with ChaCha20‑Poly1305 authenticated encryption before transmission, under a key bound to the recipient's ML‑KEM‑768 public key and to your passphrase
- Your passphrase and your private keys never leave your browser
- We only store encrypted data that we cannot decrypt
- Even our administrators cannot access your secret content
- Public keys travel with each secret: the stored payload includes the recipient's ML‑KEM‑768 public key and, when the secret is signed, the sender's ML‑DSA‑65 public key and signature. They are not secret, but they can link secrets sent to or from the same key
- Secrets are sealed to long‑term keys, so this design does not provide forward secrecy: someone who later obtains a recipient's private key and a secret's passphrase could open a copy of that secret recorded before it was destroyed
What Data We Collect
What We DO Collect
- Encrypted secret data (unreadable)
- Public keys sent with each secret (the recipient's, and the sender's when signed)
- Expiration timestamps
- Access counts
- IP addresses (for security)
- Basic usage analytics
What We DON'T Collect
- Your secret content
- Personal identification data
- Email addresses (optional only)
- Browsing history
- Location data
How We Protect Your Data
Encryption Standards
- ML‑KEM‑768 key encapsulation (CRYSTALS‑Kyber, NIST FIPS 203)
- ChaCha20‑Poly1305 authenticated encryption, keyed by ML‑KEM and your passphrase (scrypt)
- Optional ML‑DSA‑65 signatures (CRYSTALS‑Dilithium, NIST FIPS 204)
- Key vault encrypted at rest in your browser with AES‑256‑GCM
What post-quantum cryptography is and how it protects your secrets
Infrastructure Security
- Security-focused architecture infrastructure
- Automated secret destruction
- No persistent logging of secret content
- Regular security audits and penetration testing
Data Retention
Automatic Destruction
Your secrets are automatically and permanently destroyed when:
- The secret expires (based on your TTL setting)
- The maximum view count is reached
- You manually burn/delete the secret
Anonymous usage statistics may be retained for up to 2 years for service improvement purposes, but contain no personally identifiable information or secret content.