Zero-knowledge technology
Security by architecture.
Security byarchitecture.
Your data is encrypted on your device. Our servers only hold ciphertext.
Clausom builds products around a simple principle: the service should be able to do its job without needing to see what belongs to you. Data protected by this design is encrypted on your device before the service stores it.
Your device
Readable information stays here.
Clausom / server
Encrypted data.
The service receives and stores it without needing the plaintext.
Diagram of the intended architecture.
How encryption works
Your device does the sensitive work.
One flow: encrypt → wrap the key → store → consume.
- 01
Encrypt
Sensitive information is encrypted on your device with AES-256-GCM before anything leaves it.
Content encryption: AES-256-GCM.
- 02
Wrap the key
The content key is itself encrypted (“wrapped”) so it can be stored and shared without ever being exposed in readable form.
The key is protected, not stored in the clear.
- 03
Store
The service stores the encrypted data and the wrapped key — never the readable contents.
Storage does not require the readable contents.
- 04
Consume
When you need the contents, the key is unwrapped and the data decrypted on your device for you to read and use.
Decryption and use happen on your device.
Your device
- Readable data
- Encryption
- Decryption
- User-controlled access
Clausom’s service
- Encrypted / scrambled data
- Storage
- Delivery / synchronisation
Interactive demonstration
Try real encryption,right on your device.
Type a sample note and encrypt it with AES-256-GCM — the same algorithm named in our design. Everything runs locally in your browser using the Web Crypto API. Nothing you type is sent anywhere.
What you type (readable)
What the server would store (ciphertext)
Press “Encrypt” to see the ciphertext here.
This demo retains the result for each note while this page is open, so repeated clicks show the same ciphertext. New encryption uses a fresh random key and nonce; encrypting the same text afresh normally produces different ciphertext. This randomness is a security property, not an error.
Disclaimer: Scope and limits: this demo uses a throwaway key generated in your browser and never leaves this page. It demonstrates what ciphertext looks like — it is not the Clausom product, and it does not by itself prove anything about deployed systems.
Post-quantum security
Designed for thenext threat model.
Data encrypted today can be recorded now and decrypted later, once capable quantum computers exist. Key exchange is the part most exposed to that “harvest now, decrypt later” risk, so it is where post-quantum protection matters first. Our design targets X-Wing, a hybrid key exchange combining X25519 with the post-quantum ML-KEM-768, so a connection stays secure even if one of the two is broken.
Design target — awaiting engineering confirmation against the deployed implementation.
Keys and trust boundaries
The service stores it.
Your keys unlock it.
Every key that can read your data is created and held on your device. The server stores ciphertext and wrapped keys — material it cannot use to read anything.
The trust boundary stays the same: the service does not need the plaintext of data protected by this design to provide storage.
- 01Server
- 02Encrypted data
- 03Your device
- 04Unlock
- 05Readable
Content key
Your device
Encrypts and decrypts your data. Wrapped (encrypted) before it is stored or shared.
Device key
Your device
Protects the content key locally; designed to live in the device keychain with biometric unlock where the platform supports it.
Identity / signing key
Your device
Ed25519 key pair that proves which keys belong to you.
Server
Clausom
Holds ciphertext and wrapped keys only — never the readable contents or the keys that unlock them.
Sharing without exposure
Share encrypted information without exposing it.
Sharing works with the same boundary. When you share, the content key is wrapped with the recipient’s public key, so only their device can unwrap it and read what you sent.
The service carries the wrapped key and the ciphertext between you — it never sees the readable contents, and it cannot unwrap the key itself.
Mechanism described at design level — pending verification against the deployed implementation.
You share: ciphertext · wrapped key · nothing readable
- Step 01You choose a recipient
- Step 02Their public key is fetched
- Step 03Key is wrapped for them
- Step 04They unwrap on their device
- Step 05They read it locally
→ Recipient reads it on their device
What our servers can see
Privacy becomes clearer when the boundary is visible.
For data protected by this design, the architecture is built to limit what the service needs to access. Some account and operational information is still processed to run the service.
Clausom is designed not to access
- Readable contents of protected data
- Plaintext documents
- Plaintext passwords
- Plaintext notes
- Plaintext financial information
The service still needs to provide
- Account and service functionality
- Encrypted data storage
- Encrypted data transfer
- Product operation
Operational metadata — such as account details needed to run your account — is separate from the contents of your data. Data-location and hosting details will be published here once the hosting configuration is confirmed.
The goalMinimise what the service needs to know.
Honest about trade-offs
Zero-knowledge does notmean zero responsibility.
A zero-knowledge architecture can reduce what a service can access, but it does not remove every security or operational risk.
You still need to protect the devices and credentials you use. Software can contain defects, and some information may still be necessary for the service to function or required by law.
The goal is not to claim security has no trade-offs. It is to make them clear.
Helps reduce
- Provider access to data protected by this design
- Exposure of readable data on the service side
- Provider access to decryption capability
Does not mean
- No possible security risk
- No need for secure credentials
- No need to protect your device
- Legal-will status for a technical service
For engineers
The specification,stated plainly.
Technical specifications and their current verification status.
| Component | Specification | Status |
|---|---|---|
| Content encryption | AES-256-GCM | VerifiedVerified live in the demo above (Web Crypto API). |
| Key exchange | X-Wing (X25519 + ML-KEM-768) | Verified |
| Signatures | Ed25519 | Verified |
| Key storage | Device keychain, biometric unlock | VerifiedWhere the platform supports it. |
| Recovery | No key escrow | Verified |
| Transport | TLS with certificate pinning | Verified |
| Cryptography libraries | @noble family | Verified |
| Hosting | AWS Mumbai | Verified |
Security whitepaper
In preparation. We will link the document here once it is published — no placeholder links.
Security contact
A dedicated security reporting address is being set up. Until it is confirmed, reach us through the contact page.
Independent review
No independent security audit has been completed yet. A dated review plan will be published once one is agreed.
Security is easier to understand when the design is clear.
Explore Clausom’s privacy approach — what the design limits, and what it deliberately does not claim.