AshNote is a zero-knowledge platform for sharing passwords, notes, and files through encrypted links that expire after use. Everything is encrypted in your browser before upload, and team key exchange uses hybrid post-quantum cryptography so your data stays protected against both today's and tomorrow's threats.
Quantum computers threaten today's public-key cryptography. Data encrypted with classical algorithms alone can be harvested now and decrypted later as quantum hardware matures. AshNote doesn't wait for the threat to arrive.
All team and vault key exchange uses a hybrid key encapsulation mechanism combining X25519 (elliptic-curve Diffie-Hellman) with ML-KEM-768 (FIPS 203), a NIST-standardized post-quantum lattice-based KEM. Both shared secrets are combined through HKDF-SHA-256, meaning that if either primitive is ever broken, the other still protects your keys.
Classical layer
X25519 ECDH
Battle-tested elliptic curve key agreement
Post-quantum layer
ML-KEM-768
NIST FIPS 203 lattice-based KEM
Key derivation
HKDF-SHA-256
Both secrets combined: neither alone is sufficient
A different kind of trust
Compliance audits prove a vendor has the right policies on paper. They don't prove your data was actually encrypted.
A SOC2 report says the right things were said about how a company handles your data. It doesn't show you that the server can't read it. It can't catch a backdoor added between audit cycles. It can't show you the math.
Zero-knowledge is a different kind of promise. One you can verify yourself, in your own browser, in less than a minute. No badge required.
Verify it yourselfDon't take our word for it
Zero-knowledge claims should be auditable. Open your browser's developer tools and watch AshNote encrypt your content on your own machine before a single byte leaves for our servers. If the plaintext ever appears on the wire, we're not doing our job.
Cmd + Option + I. Switch to the Network tab.canary-plaintext-42, set any password, and click Create Secret.CreateSecret. Click it and open the Payload tab (Chrome) or Request tab (Firefox).Cmd + F inside the request details and search for canary-plaintext-42. It won't appear. Your password won't either.encryptedPayload, wrappedKey, and encryptedMetadata: bytes that can only be opened with your password.Visible on the wire (by design)
kdfParams.salt: Argon2id salt, safe to publishNever transmitted
No security through obscurity
Every cryptographic primitive AshNote uses is either native to your browser or a public open-source library loaded in your frontend bundle. Nothing hides behind a server endpoint, and nothing is a bespoke in-house implementation you'd need to take on faith.
Browser-native: Web Crypto API
AES-256-GCM : content encryptionAES-KW : key wrappingX25519 : classical key agreementHKDF-SHA-256 : hybrid key derivationW3C-standardized and implemented inside Chromium, Firefox, and WebKit by the same engineers who secure every HTTPS connection you make. Not a JavaScript reimplementation: your browser's own audited native code.
We can't hide a backdoor in browser-native code. Browser vendors control that. We can't hide one in the open-source libraries. Anyone can read them. Everything a bad actor would want to compromise is out in the open, both for them and for you.
Most sensitive information is still shared the wrong way.
Passwords get pasted into chat. API keys sit in email threads. Internal documents get attached to systems that were never designed for transient disclosure. Once shared, that information often lingers in inboxes, chat history, backups, and searchable archives long after it was needed.
AshNote was built for a simpler model:
Encrypt it, share it, expire it.
Instead of assuming sensitive information should live forever in ordinary communication systems, AshNote is designed to make access temporary and exposure narrow.
AshNote's core sharing model is simple: create a secret, send the link, and let it be deleted after viewing or expiry, whichever comes first.
Once a secret is viewed or reaches its expiration time, its encrypted data is permanently removed from our service. After that, access is no longer possible.
Secrets are encrypted client-side before they leave the browser. The server receives and stores encrypted payloads and required metadata, not readable plaintext.
Passwords used to protect secrets are handled locally and used to derive cryptographic key material in the browser. Team and workspace key exchange is protected by the hybrid post-quantum KEM described above. The service is designed so secret content remains unintelligible to the server.
AshNote supports both notes and files. Files are encrypted in the browser before upload and can be shared using the same expiring-link model as text secrets.
That makes AshNote useful for more than passwords alone. It works for PDF files, internal notes, credentials, screenshots, certificates, and other sensitive materials that should not live indefinitely in standard messaging systems.
AshNote is built around reducing retained exposure.
Small secrets can be handled with minimal persistence, while larger secrets and files can be stored as encrypted objects until they are redeemed or expire. In either case, the system is designed so the service stores ciphertext, not usable content.
For teams that need more than one-to-one sharing, AshNote provides encrypted file vaults. Vault keys are distributed using the same hybrid post-quantum KEM that protects all key exchange in AshNote, ensuring your shared files are protected against both current and future threats.
Access rules, expiry behavior, and optional vault passwords are layered on top without changing the zero-knowledge architecture. Files are encrypted and decrypted in the browser -- the server never sees plaintext content.
Sensitive information does not belong in ordinary communication history.
| Chat / Email | Password Manager | AshNote | |
|---|---|---|---|
| Designed for temporary disclosure | No | Limited | Yes |
| Content encrypted before upload | No | Varies | Yes |
| Single-use sharing flow | No | Limited | Yes |
| Hard expiry support | No | Limited | Yes |
| Encrypted file sharing | Limited | Limited | Yes |
| Post-quantum key exchange | No | No | Yes |
AshNote is not trying to replace chat, email, or general file storage. It is built for the narrower and more important case where information should be shared securely and retained as little as possible.
If the information should not sit in someone's inbox forever, AshNote is the right kind of tool.
Share privileged drafts, confidential attachments, or sensitive deal material through expiring encrypted links instead of ordinary email threads.
Reduce plaintext exposure when exchanging records, results, or other sensitive information between intended parties.
Send wire details, tax documents, or account-related information through a channel designed for temporary access.
Share API keys, SSH material, credentials, certificates, and internal notes without leaving them in chat history.
Move routing numbers, identification records, and closing documents through expiring encrypted delivery rather than static attachments.
Share Wi-Fi passwords, insurance cards, logins, and other everyday sensitive information with less long-term exposure.
AshNote is built around a small set of architectural rules.
Encryption happens before upload, and decryption happens in the recipient's browser.
Secrets are not meant to remain available indefinitely by default. Access windows should be explicit and limited.
Unread secrets should not become forgotten liabilities.
AshNote is designed for the moments when email, chat, and generic storage are the wrong tools.
Hybrid X25519 + ML-KEM-768 key encapsulation protects team key distribution against both current and quantum-era adversaries.
Most systems assume retention. AshNote assumes limitation. Instead of creating another permanent copy of something sensitive, AshNote gives you a way to share it through encrypted, expiring access designed to narrow exposure from the start.