Security, in plain words
What CryptoUpload protects, what it does not, and how to tell us when we got something wrong.
What it is built to withstand
- A provider that is curious but honest
- It sees encrypted bytes, file sizes and the times things were written. It should not be able to work out what a file contains or what it is called.
- A provider that is hostile or compromised
- It may hand back an old copy, cut a file short, reorder blocks or leave things out. Each of these is caught: the vault keeps an authenticated record that can only move forward, the end of every file is checked, and every block knows its place. Syncing stops. Limits: a computer opening the vault for the first time trusts what it is served, and a provider can withhold the newest changes from a device that has fallen behind.
- Someone who copies the stored files
- Without the password or the 24 words they hold unreadable data. The password goes through Argon2id, so every guess costs 256 MiB of memory.
What a provider can still see
- Always
- How many files and folders there are, the size of each file, how long each name is, when each object was written, and the address the requests come from. That it is a CryptoUpload vault. Also: how many items each folder holds, which unlock methods exist, members’ public keys and, in the basic profile, the names you gave members.
- With the optional private profile
- File sizes are rounded up (by at most about 12 per cent), name lengths fall into five bands, and the README in the vault is left out. Decoy files can also hide how many files each folder holds, but only from someone who gets a copy of the storage: a provider that logs requests can tell decoys apart. Counts of folders, request times and the address stay visible.
- A limit of the format
- Size and time can be enough to recognise a file that is already known, for example a film whose exact size is public. The basic profile does not hide this.
What it does not cover
- A computer that is already compromised
- Anyone who controls an unlocked computer controls the vault on it.
- What you have to trust
- Cloud credentials are kept in an encrypted file on your computer. Updates are trusted through one signing key held by the author. A program running as you while the vault is open can read your files.
- A provider that refuses to serve you
- Tampering is detected. Denying service is not something encryption can prevent.
- Taking access back
- Changing a password, or removing a person from a shared vault, does not undo what they already saw. Removing a person protects what is written afterwards. For a complete revocation, create a new vault and copy the content across.
- Hidden vaults
- There is no deniability: a vault can be recognised as a vault.
- Forgetting everything
- If you lose both the password and the 24 words, the data cannot be recovered by anyone.
No independent audit yet
- What exists
- An internal security review, done in October 2026. It is not an independent audit.
- What we ask of you
- Do not make CryptoUpload the only protection for information that would seriously harm you if it were exposed. The plan is to apply for grants to pay for an independent audit. The code is public: anyone with the skills can review it and report what they find to security@cryptoupload.org.
Report a vulnerability
- How
- Write to security@cryptoupload.org. Please do not open a public issue for a vulnerability. If you can, include the version, the steps to reproduce, the impact you estimate, and a proof of concept.
- In scope
- Any way to read plaintext, forge a seal or recover a key without the password or phrase; any silent loss of data while syncing; any way to extract stored credentials; the network backends (unauthenticated requests, path traversal, request forgery); the command line and the app.
- Out of scope for now
- Findings that need continuous physical access to a computer that is already unlocked; denial of service against cloud providers, which are not ours; general robustness bugs with no effect on real data.
- What to expect
- We confirm we received your report within 5 working days and agree a disclosure window with you, 90 days by default. There is no bug bounty.
What stays visible, item by item
| On the provider’s side | Basic profile | Private profile |
|---|---|---|
| File contents | Unreadable | Unreadable |
| File and folder names | Unreadable | Unreadable |
| Size of each file | Exact | Rounded up, by about 12 % at most |
| Length of names | Exact | One of five bands |
| Files in each folder | Exact number | Rounded up with decoys on; a provider that logs requests can tell decoys apart |
| Number of folders | Visible | Visible |
| When each block arrives | Visible | Visible |
| Address you connect from | Visible | Visible |
The private profile is optional and chosen when you create the vault. With either profile you can shuffle the order and timing of uploads and route traffic through a proxy.